Community
Participate
Working Groups
Build Identifier: 20100617-1415 Just upgraded to Eclipse IDE for C++ Developers (Helios). My project has the following folder structure: <project_root>/ dir1/ linux_debug/ built .o and final target files for a debug build linux_release/ built .o and final target files for a debug build source files ... dirN/ linux_debug/ built .o and final target files for a debug build linux_release/ built .o and final target files for a debug build source files I'd like to create a single top-level resource filter against the <project_root> that would exclude all "linux_release" and "linux-debug" folders along with any files in those folders. I have tried the following resource filters and none works. When I click "Apply" in the "Resource Filters" dialog, there is a short delay, then the folders matching the pattern disappear, and then reappear again after another short delay. 1. Filter type: "Exclude All", Applies to: "Files and Folders" + "All children(recursive)", "Name" "matches" "linux_*" 2. Filter type: "Exclude All", Applies to: "Folders" + "All children(recursive)", "Name" "matches" "linux_*" 3. Filter type: "Exclude All", Applies to: "Files and Folders" + "All children(recursive)", "Project Relative Path" "matches" "*/linux_*" 4. Filter type: "Exclude All", Applies to: "Folders" + "All children(recursive)", "Project Relative Path" "matches" "*/linux_*" Reproducible: Always
I am not able to reproduce the issue. I downloaded the exact same build (Eclipse IDE for C/C++ Developers, Build id: 20100617-1415), then created a project as you specified, and added the following resource filter on the project itself: Filter type: "Exclude All", Applies to: "Files and Folders" + "All children(recursive)", "Name" "matches" "linux_*" Clicked apply, all the linux_* sub directories disappeared, along with their content. Clicked OK - same.
(In reply to comment #1) > Filter type: "Exclude All", Applies to: "Files and Folders" + "All > children(recursive)", "Name" "matches" "linux_*" Note that: Filter type: "Exclude All", Applies to: "Folders" + "All children(recursive)", "Name" "matches" "linux_*" Works too.
Created attachment 172585 [details] Project that shows there's no problem Sample project used for (not) reproducing the issue. Choose "File/Import.../General/Existing Projects into Workspace/Select archive file:" to import the project, then verify that the folders are not displayed, and that the resource filter is set.
Well, I've imported "my_project" from the above attachment into the same workspace as my main project. Resource filters do work for "my_project", and an identically defined resource filter in <project_root> (my real-life project) still do not work. Suggestions?
(In reply to comment #4) > Well, I've imported "my_project" from the above attachment into the same > workspace as my main project. Resource filters do work for "my_project", and an > identically defined resource filter in <project_root> (my real-life project) > still do not work. > > Suggestions? can you attach your project to this bug report? Or a subset of your project that illustrate the issue?
I cannot attach my project's source code - it's a proprietary application. Is there anything that could be done to the project's *.sc file perhaps? Also, I've just noticed that once a project has a resource filter defined, it can no longer be renamed as Eclipse claims is's out of sync with the filesystem. Removing the resource filter makes the project renameable again.
Also, what is the difference/relationship between the Resource Filters (Resource->Resource Filters and Source Filters (C/C++ General->Paths and Symbols->Source Location->Edit Filter)? The former appears to use standard shell globbing for pattern matching, while the latter seems to use ANT-style patterns ...
Also, I've noticed that the resource filter's details are stored in the .project file in a single string that uses '-' as the separator between different parts of the filter. What if the pattern specified contains '-'?
(In reply to comment #6) > I cannot attach my project's source code - it's a proprietary application. Is > there anything that could be done to the project's *.sc file perhaps? > I think I can reproduce it with a CDT MinGW project, I'll get back to you about it. > Also, I've just noticed that once a project has a resource filter defined, it > can no longer be renamed as Eclipse claims is's out of sync with the > filesystem. Removing the resource filter makes the project renameable again. This is a bug: I created a new bug to track it: 317824
(In reply to comment #8) > Also, I've noticed that the resource filter's details are stored in the > .project file in a single string that uses '-' as the separator between > different parts of the filter. What if the pattern specified contains '-'? The only part that is configurable by the user is the last segment, therefor it can contain any number of "-" and does not prevent parsing the content properly. You can try for yourself with a pattern that contains a "-", and it works properly.
(In reply to comment #7) > Also, what is the difference/relationship between the Resource Filters > (Resource->Resource Filters and Source Filters (C/C++ General->Paths and > Symbols->Source Location->Edit Filter)? The former appears to use standard > shell globbing for pattern matching, while the latter seems to use ANT-style > patterns ... The CDT source filter is built on top of the core resources. The Resource Filters apply at the lowest level, preventing resources to be created at all, allowing very large directories to be filtered with a minimal impact on performance. The CDT feature only prevent the CDT tools to consider existing resources for its own features (indexing, building, etc...). The CDT feature was designed when Resource filters did not exist, while resource filters apply for all features, not only the CDT. Then, Resource filters are much more powerful, allowing file attribute comparison (modified date, etc...)
This is actually caused by 311189, where a recent change in CDT 7.0 causes a refresh local for a resource that doesn't exist in the workspace (because it is filtered out), but exist in the file system nonetheless. The proper fix will be in the core.resources to prevent clients from doing so, but in the mean time, the CDT can be patched to avoid this bug as well (see included patch).
Created attachment 172633 [details] Patch for the CDT (to make it work until the Platform is patched)
Created attachment 172634 [details] Patch for the Platform patch for the platform - junit test to come.
Comment on attachment 172633 [details] Patch for the CDT (to make it work until the Platform is patched) Thanks Serge! I've put the fix into our 7.0 branch and HEAD. Presumably once the fix is in the platform this can be removed, but it looks pretty innocuous.
*** cdt cvs genie on behalf of jblackburn *** Bug 317783 Resource filters don't appear to work -- work-around for platform issue in 3.6 [*] ResourceChangeHandler.java 1.15.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/model/org/eclipse/cdt/internal/core/settings/model/ResourceChangeHandler.java?root=Tools_Project&r1=1.15&r2=1.15.2.1 [*] ResourceChangeHandler.java 1.16 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/model/org/eclipse/cdt/internal/core/settings/model/ResourceChangeHandler.java?root=Tools_Project&r1=1.15&r2=1.16
Created attachment 172638 [details] JUnit test Regression test for the core resources
(In reply to comment #16) > *** cdt cvs genie on behalf of jblackburn *** > Bug 317783 Resource filters don't appear to work -- work-around for platform > issue in 3.6 > > [*] ResourceChangeHandler.java 1.15.2.1 > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/model/org/eclipse/cdt/internal/core/settings/model/ResourceChangeHandler.java?root=Tools_Project&r1=1.15&r2=1.15.2.1 > > [*] ResourceChangeHandler.java 1.16 > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/model/org/eclipse/cdt/internal/core/settings/model/ResourceChangeHandler.java?root=Tools_Project&r1=1.15&r2=1.16 That's great, thanks James!
Now fixed on head.
(In reply to comment #19) > Now fixed on head. Serge this should probably go into R3_6_maintenance (when it's open) as it's a bugfix and 3.7 is a year away.
It looks like a good 3.6.x candidate indeed. We can now open R3_6_maintenance. BTW, Serge you should update the summary, since it sounds a bit scary ;) I think it's a part of the bug triage process. A question about the fix. Isn't it enough to just check if the resource being refreshed exists?
(In reply to comment #21) > A question about the fix. Isn't it enough to just check if the resource being > refreshed exists? Ignore the question :-)
Created attachment 172926 [details] Something to look at Serge, could you look at this patch? I think it solves the problem but in a different place. I'll attach another idea in the next patch.
Created attachment 172927 [details] Idea v02 Another idea.
Created attachment 172928 [details] Idea v03 This one looks like something more general. For UnifiedTreeNode a filtered file is a file that does not exist in the filesystem. But I haven't run all tests :-)
(In reply to comment #25) > Created an attachment (id=172928) [details] > Idea v03 > > This one looks like something more general. For UnifiedTreeNode a filtered file > is a file that does not exist in the filesystem. But I haven't run all tests > :-) Does this do exciting things if someone filters .project?
(In reply to comment #26) > (In reply to comment #25) > > Created an attachment (id=172928) [details] [details] > > Idea v03 > > > > This one looks like something more general. For UnifiedTreeNode a filtered file > > is a file that does not exist in the filesystem. But I haven't run all tests > > :-) > > Does this do exciting things if someone filters .project? I like v02, but v03 sounds a bit too broad scope, since some code may depend on that call to return whether it exists in the file system independently of the filters. What do you think?
(In reply to comment #27) > I like v02, but v03 sounds a bit too broad scope, Well, all tests pass with v03. > since some code may depend on > that call to return whether it exists in the file system independently of the > filters. This is an internal method, so we can easily verify that.
*** Bug 323465 has been marked as a duplicate of this bug. ***
*** Bug 317956 has been marked as a duplicate of this bug. ***
