Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #143458 +++ * 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 parent dirctory is refreshed, but also the selection is lost. We should never change a user's selection. Multiple selected files should also work. 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. Note that there is also bug 180671 related, which requests checking remote timestamp and potentially refreshing on a double click operation. This also requires the selection to be retained.
This bug was (partially) introduced when fixing refresh of leaf nodes. See bug #143458 comment 7 for a detailed explanation. There seem to be two cases a) Local refresh on Local File Subsystem (supportsDeferredQueries==false). In this case, the SystemView should be able to retain the selection, since everything happens in one thread. b) Remote refresh when supportsDeferredQueries==true. In this case, the refresh is done in a separate job, so restoring the selection can only be done when that job is complete. The refresh job may need a callback into the SystemView when it is done, with the callback holding the original selection, so the selection can be restored. Also note that in case (b) where the deferred refresh can be really slow, if the user modified the selection himself before the job was complete, the original selection may *not* be restored. Fixing case (b) may require API changes as described in bug #173042. Fixing case (a) should be relatively easy, so I'd love to see (a) fixed for TM 2.0 -- looks like the fix needs to go into the SystemView, and/or into SystemRefreshAction as per bug #143458 comment 7.
Fixed case (a) in SystemRefreshAction by sending EVENT_REFRESH_REMOTE which retains the selection. Fixed case (b) in SystemDeferredTreeContentManager and SystemViewLabelAndContentProvider, by running a callback after the deferred refresh job is complete. Selection is restored if the selection at the time the job is complete is a subset of the selection at the time the job was started. This fix has the following limitations: - does not work if a multi-select spans multiple levels of parents, since in this case multiple nested refresh jobs are needed which are not sent (only the outmost parent is really refreshed). - does probably not work if a refresh returns new or modified items that do not compare equals() with the previous item in the selection. This may be fixed rather easily, however, by sending an EVENT_SELECT_REMOTE with the absolute paths of the selected elements rather than directly doing setSelection(). Changeset: [181145] Restore selection after refresh
Martin, I tested with I20070515-1830. Selected a list of files and renamed one of them outside RSE and it wasn't included in the selection after refresh, as I would expect. I removed files and added files to the directory that were and weren't selected. It behaved as you would expect. One (regression) issue is if you select multiple folders and do a refresh. Only one of the folders is selected after. I noticed that refreshing folders now expands them where before collapsed folders weren't expanded on a refresh. Same thing happens with filters.
(In reply to comment #3) > One (regression) issue is if you select multiple folders and do a refresh. > Only one of the folders is selected after. In case more than one from the multi-selected folders were opened before the refresh, this is not really a regression: earlier RSE versions refreshed only the first folder in this case, the new version refreshes all. Maintaining the selection in the case where multiple Refresh jobs are scheduled is very hard at least, I'm not sure if I can fix this. > I noticed that refreshing folders now expands them where before collapsed > folders weren't expanded on a refresh. Same thing happens with filters. This is a pretty problematic regression, I filed bug #187205 to track this. Thanks for testing my fix. If you can have another look at it, I'd also be interested if the Refresh events are properly reflected in a Table (Remote Systems Details View): * Refresh an element in the table -> is it updated in tree and table? * Refresh an element in the tree which is also shown in table -> is it updated? * In the tree, Refresh the parent of an element shown in table -> update? * In the tree, Refresh a grandparent of an element shown in table -> update? Thanks!
Hi Martin, * Refresh an element in the table -> is it updated in tree and table? --> You mean just refresh the table view? As you can't click on files/folders in the table view and do a refresh. Bug 187016 is open for that. --> This work's fine. * Refresh an element in the tree which is also shown in table -> is it updated? --> I renamed a file outside RSE. Went back to the Remote Systems Tree View and tried to refresh that file. The file wasn't renamed and it's icon was changed to a directory. If I refresh the parent directory of that file it's name is fixed or if I select other files in that directory it's name is fixed. This was on a Local Windows machine. Same thing occurs if I delete a file outside the RSE and try to refresh that file inside RSE tree. Also occurs for folders. The directory isn't being refreshed, as if I added files outside the RSE they aren't shown. --> As long as you aren't refreshing the file that is renamed/deleted it works okay. * In the tree, Refresh the parent of an element shown in table -> update? --> This worked fine. * In the tree, Refresh a grandparent of an element shown in table -> update? --> The tree is updated, but the table does not get refreshed. Weird behavior started occurring after where certain things that did work wouldn't work after. I created a new workspace and tried everything from scratch again. Dragging and dropping a file in the tree view to a folder that is shown in the table view doesn't cause the table view to be updated. Same with using Move.
My comments previously were all related to trying it on a local windows connection. For FTP connections is refresh handled differently? For the grandparent of a file shown in the remote system details view if I refresh it, then in the tree only that folder is refreshed and all subtree's are collapsed. I can understand this as FTP is slower, but should the subtree's be collapsed? Everything else worked correctly on FTP. For DStore: Dragging and Dropping files (in the tree) to a folder that is shown in the table does not refresh the table view. Same with using Move. * In the tree, Refresh a grandparent of an element shown in table -> update? --> The parent element of the files in the table is collapsed in the tree view and the table is not updated. Everything else worked okay on dstore. Also pasting of files in the tree does not refresh the table view for local, ftp, or dstore. If you paste a file in the Remote System Details View the table view is not refreshed, but the tree view is. Martin are there any other case's you would like me to try? If anything is unclear let me know and I'll go through it again.
Bug 187285 relates to the refreshing issue I have mentioned that on remote connections sub-directories of the directory you are refreshing become collapsed.
Yes, Refresh on Local is handled differently than on any remote connection: On Local, the queries are always synchronized so the refresh is able to walk over multiple stages. For remote, queries are typically deferred into Eclipse Jobs in order to not block the UI; because of that, they cannot work over multiple levels. This is a known limitation and has been like that since openRSE 1.0. Not refreshing the TableView is yet another issue, is there a separate bug for this? Thanks!
Thanks for testing so many cases, I think we have a very good handle on things now. If you could create separate bugs so we can track the separate issues separately, that would be perfect. Thanks!
I don't see a separate defect for refreshing the table view, except for bug 187015 which is just for dragging and dropping files into the table view. Want to me to put them all in that one and change the summary or open a new bug? I'll also open bugs for the issue's with refreshing the tree view.
I also noticed that if I deleted a file using "rm" command from shell, and then refreshed its parent folder in the RSE tree view, the file was still shown there. If I right click on the file, and selected Delete menu, I got the message: Deletion of object failed. This happened on DStore connection (both AIX and Linux I tried). Worked fine for local connection. I tried on driver RSE-SDK-I20070516-1300.zip.
(In reply to comment #11) > I also noticed that if I deleted a file using "rm" command from shell, and > then refreshed its parent folder in the RSE tree view, the file was still > shown there. Xuan, this sounds like a major bug. I find it extremely important that "Refresh" works reliably, i.e. after refresh is done it must show the correct contents of the items on the remote side. Can you please file a separate bug for this with severity Major since this has nothing to do with the selection issue handled here. Include the information you gave in your comment as well as the subsystem you've testing on (local, dstore, ssh). Thanks!
Bug 187670 has been created for the refresh problem for deleted file.
[target cleanup] 2.0 M7 was the original target milestone for this bug
