Community
Participate
Working Groups
The first time I tried this it happened right away, but since then to reproduce it has taken a couple of tries. Steps to Reproduce: 1. Find a folder you are going to rename and right click on it and select Show in Table. 2. Rename the folder from the Remote Systems View. 3. Repeat Renaming till the table view shows an error. The error shown in the table view is: The folder "PATH TO FOLDER" is not readable. Cannot expand. -----------Enter bugs above this line----------- TM 2.0RC3 Testing installation : eclipse-SDK-3.3RC4 RSE install : RSE 2.0 RC3 java.runtime : Sun 1.5.0_11-b03 os.name: : Windows XP, Service Pack 2 ------------------------------------------------
I could always recreate it using just two renamings. I did some debugging and this is what I found. When we put this folder into Table view, the LocalFile object is the _inputObject of this table. When we do the first rename of this folder in System View, inputChanged event is triggered, and setInput() method of the table view is called. At this point, the _inputObject is still the same object as before. Then, the rename operation will trigger an internal refresh of its parent. While doing internal refresh, we rebuild the children of its parent (create new LocalFile). So the LocalFile of original folder actually get recreated. This causes inputObject of the table view not corresponding to the same LocalFile object of this folder in System view During the second rename action in the System View, the name of the LocalFile object corresponding to the tree view items in the System View got updated. But not the _inputObject of the table view. And then this SystemTableView#sytemRemoteResourceChange() method will be triggered. At the very beginning of this method, it did a refresh(): if (_objectInput instanceof ISystemContainer && ((ISystemContainer)_objectInput).isStale()) { provider.flushCache(); refresh(); return; } But this refresh() still use the old _objectInput which still contains the name after the first rename. At this time, this corresponding folder has been renamed to a different name. That is why we got this error.
The problem is in the SystemTableViewPart#systemRemoteResourceChangeEvent() Right now, it only check if the changed object is equal to the _inputObject of the table view part. We need to also compare their absolute path (including the subsystem name) to determining if the changed object indeed refers to the same remote resource of the _inputObject, since the object itself could be restructured during the process of renaming or refreshing. And it also seems to me the order of processing the remote change event should be SystemTableViewPart first, then SystemTableView, since during the event of handling SystemTableViewPart, the _inputObject of this table could be changed. This change will impact the process of change event in SystemTableView.
Created attachment 72367 [details] Fixes to make sure the _inputObject are corectly updated during renaming. Two changes in this patch: . Change the order of adding SytemTableView and SystemTableViewPart into the SystemResourceChangeManager so that SystemTableViewPart#systemRemoteResouceChangeEvent() could be called before SystemTableView#systemRemoteResouceChangeEvent(). . Adding the comparison for the fullAbsolutePathName of the _inputObject and changed resource object (old name) to make sure if they point to the same remote object, we will update the _inputObject of the table view.
Patch looks OK - only comment I have is that it seems comparing two objects by absolute name is an operation that's supposedly needed more frequently. We should put it in a common location, at least "internal" for 2.0.1 if not API for 3.0. But we can also just apply this patch for 2.0.1 and then create a new enhancement request bug for moving that code to a common location.
I've applied the patch to cvs.
Bug 194838 has been open to track moving the comparison code into a common place.
Xuan - your Legal Message is missing here, can you add it please?
Legal Message: I, Xuan Chen, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
Verified with I20070705-0600.
