Community
Participate
Working Groups
To reproduce, we used Windows with RSE 2.0.0.1. Steps to reproduce: - Expand Local Files node - Create new filter: - Folder: C:\ - Subset by file type: *.txt - Name: C:\ - Expand filters Drives->C:\ and C:\ - Expand a subfolder - Create a set of new files like 123.txt, 123.abc, 123.uvw - Select the folder and refresh (F5) From now on, it is unpredictable which content is shown for the same folder under the two different filters. We had combinations of showing the Drives->C:\->subfolder the _filtered_ content of the C:\ filter or one of the two folder shown no content or one or both folders show incomplete content .... The expected behaviour is that even if the folder is the same element, a refresh event for the folder needs still to refresh both instances, the content (children) of the folder must be correct filtered and complete corresponding to the parent context.
I reproduced the issue. This is likely a problem with SystemView refresh and/or the ElementMap. Assigning P1 since this is a risky area to touch but a must fix for 2.0.1 Here is what I did on WinXP / Sun 1.6.0_01 / RSE HEAD of 19-Jul: - Expand Local Files node - Create new filter: - Folder: C:\ - Subset by file type: *.txt - Name: C:\ txt - Expand "Drives->C:\->tmp" and "C:\ txt->tmp" (has one subfolder but is empty otherwise) - With "Drives->C:\->tmp" selected, right-click > Create new file: "test.123" --> test.123 is not shown in SystemView --> After Refresh (F5) it is still not shown --> Launch shell and typing "dir" shows the file Expected behavior: After "Create file" the file must be shown under "Drives->C:\->tmp" only. After Creating another file "test.txt" it must be shown under the folder in both filters.
More info: After the previous steps, when I refresh the parent filter (Drives->C:\) the file gets visible under Drives->C:\->tmp. When I now refresh "C:\ txt" the file gets invisible again under Drives->C:\->tmp It looks like there is only a single instance of the folder C:\tmp which remembers its contents in kind of a cache regardless of what filter was used when getting the children. So, when getting the filtered children the new cached contents is also applied to the folder which should show the unfiltered children. Changed the summary accordingly (previous value was: "Child folders of filter does not show correct content")
I could not reproduce the issue with SSH -- everything worked as expected there. Marking as [local] only. This could be an issue with refresh, since SSH performs delayed refresh whereas local performs synchronous refresh. This is still a very important issue for us, since our commercial product works the same way as Local.
Just as additional side-note in reply to comment #2: It is essential that the two (or more) occurences of the same element are indeed representing the same data model element. That is important to known, because the data model element may change it's state dynamically and all tree node representing that data model node must refresh possible decorators correctly. Nonetheless, the child tree of a filter needs to show only the elements that matches the filter, throughout the whole child tree depth.
Here is a setup to test the scenario slightly easier - a bug is there even without a "name filter": - mkdir C:\tmp\aatmp\testfolder - Under local files, create filter: 1. Name=aatmp1 Dir=C:\tmp\aatmp 2. Name=aatmp2 Dir=C:\tmp\aatmp The advantage of this setup is that C:\tmp\aatmp does not have so many children, so both filters can be expanded side by side and refreshed. But the bug shows immediately: Expand both filters --> aatmp2 shows no children (should be:testfolder) Refresh --> aatmp2 never shows any contents With the SSH subsystem, everything works as expected. Back with the original setup for reproducing the bug, I switched tracing on for SSH, and after adding files on remote and pressing refresh on one filter, I was surprised to see that - both occurrences of the folder are refreshed properly - even SftpFileService.internalFetch() is only called once, so the subsystem must be able to satisfy both the filtered and the unfiltered query with a single remote query. This is an indication that indeed the same model element is used, as Uwe noted in comment #4. Impressive! So I hope we can fix the refresh issues on Local as well.
Created attachment 74159 [details] patch to use filterstring when no separator Can you see if this patch helps?
The patch solved the scenario as described here for the Local connection.
The fix is in cvs now.
