Community
Participate
Working Groups
Build ID: HEAD Steps To Reproduce: Resource filters appears to interact badly with aliases. Steps: 1) Create two projects p1, p2 Create real folders & files: p1/src/foo.c p1/src/foo.h Create group: p2/g1 Create link: p2/g1/src -> p1/src Problems: 1) Add a resource filter "Include Only Files: *.c" to p1/src (.h files disappear from p1 (and sometimes from p2 too...) 2) Add a resource filter "Include Only Files: *.h" to p2/g1/src Having done (2) p1/src is now empty for me (or it contains foo.h file). The apparent behaviour changes each time I go through these steps... Close & open p2, resource re-appear as you expect in both projects. Delete the resource filter on p2/g1/src Create file 'asdf' in p1/src. File appears in p1 even though it's filtering *.c, but doesn't appear in p2 even though it has no filter... Given what I see when I do the above is inconsistent, this is really worrying. If I close the project which has aliases, behaviour becomes predictable again...
Thanks for reporting this issue James. This is now fixed on the e4 resource CVS HEAD (org.eclipse.core.resources and org.eclipse.core.tests.resources).
*** Bug 266666 has been marked as a duplicate of this bug. ***
Created attachment 128007 [details] Test1 Add #testCreateFilterLinkedFolderAndTarget2 test which tests that creating and modifying resources works as expected. The resources are selectively included and filtered in two different linked folders as in your original test. The main difference between this test and yours is that the modification here is done in the workspace rather than externally. If you uncomment the two #refreshLocal() calls, the aliases folders contain the resources you would expect and the test passes. If you don't then too many resources hang around.
Problems still occur, reopening
This is now fixed on the e4 CVS HEAD. The regression test listed in the attachment now passes without errors. Note that there's still one case under which it's possible to create a resource under a folder that would normally be excluded under a refreshLocal(), and this is if the user explicitly creates a resource under that parent. For example, lets say that "P1/folder" excludes all "*.h" resources. If the user creates explicitly a resource named "foo.h" under "P1/folder" (and not under any of its aliases), then the resource will show under that folder, until the user manually do a refresh. This is to avoid the very confusing case that would prevent the resource from even being created if if was excluded by its parent. This is by design.
(In reply to comment #5) > ... > This is to avoid the very confusing case that would prevent the resource from > even being created if if was excluded by its parent. > > This is by design. That's fine, and makes sense to me.
