Community
Participate
Working Groups
* Select a file in the RSE Tree view (e.g. on dstore connection), and look at its time stamp. * Modify that same remote file (from another dstore connection, or ssh, or directly on the remote). * Back to the original dstore connection, observe that the timestamp is old. * With the file selected, choose right-click > Refresh. The timestamp is not updated. * Select the directory above and choose right-click > Refresh. Now the timestamp gets updated. When a file (or other resource) is explicitly selected for refresh, a refresh should be performed. Same for multiple selected files. RSE should be intelligent enough to perform the minimal amount of required operations to perform refresh of any multi-selection. This is required in order to be consistent with "Refresh" on the local resource system. Workaround: when you want to refresh, always refresh directories (or filters) only.
I'd love to see this fixed for 1.0.1 since it severely impacts user experience. The minimal fix I'd like to is that when a list of resources [x,y,z] is selected for refresh, the actual refresh is done on the parent directories of the resources in order to ensure correct display to the user.
Local is ok, but the problem is easily reproducible through dstore. It is a serious bug since RSE does not reflect the file properties correctly even after a refresh.
There's no easy to refresh for a property change. This needs to be looked at and some API needs to be in place. Changed org.eclipse.rse.ui.actions.SystemRefreshAction to refresh parent directories.
Ignore immediate comment above (bugzilla problem). This is the relevant comment: There's no easy way to refresh a leaf node. This needs to be looked at in more detail and instead of resolving for children, we probably need to . Changed org.eclipse.rse.ui.actions.SystemRefreshAction to refresh parent directories which could mean a performance degradation in some cases. A common parent is only refreshed once to mitigate the performance degradation.
The refresh on the file node does now refresh the parent, and consequently the child, however the original selection is lost.
reopening so that the selection regression can be fixed.
The selection is indeed lost. I've tried various things to set the selection. There is code in SystemView that explicitly clears the selection before refreshing the parent if the selection are the children of the parent. I'm not sure why that is done. Setting the selection of the children in the refresh action after firing the event to refresh the parent does not work because the refresh event is handled in a job and the parent refresh may not be complete (so the child is not found in the tree). So it looks like SystemView will have to change to clear the selection, refresh the parent, and then select the new children again. This will have some performance impact, likely the reason why it's not done this way currently. I will have to do some testing with a large number of selections with different parents. This change, if we proceed, will have to be done in 2.0. Also note that in Windows Explorer, if something is selected in the tree view and refreshed, the selection is maintained. However, if a file is selected and refreshed (from the "table" view), the selection is lost. Martin, I would like your opinion on this. Is it ok to close this defect and open a separate defect for 2.0, or leave this defect open and change the target to 2.0?
Closing per M6 since the refresh is done. Opened bug 181145 for keeping the user's selection.
[target cleanup] 2.0 M6 was the original target milestone for this bug
