Community
Participate
Working Groups
(from vkrevs@yahoo.com) Build Identifier: 20100617-1415 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 Create a new resource filter: Filter type: "Exclude All", Applies to: "Files and Folders" + "All children(recursive)", "Name" "matches" "linux_*" Attempt to rename the project. 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. Reproducible: Always
Serge, it looks like a pretty serious limitation. Have you had a chance to verify that?
I experience similar problem when renaming projects with filters.
Serge, is it still M1?
Created attachment 175718 [details] Fix Yes, this is the patch for this bug. It turned out to be a bug in the core.resources plugin. Can you review it please? Thanks,
I think that the problem is more complicated. Try to copy a project with some filters defined. Filters are lost in the destination project. It seems that the root cause of the problem is similar, i.e. we save the project description in a wrong place.
Moving to M2.
Created attachment 175984 [details] Fix Fix. Now also address the disappearing of resource filters when the project is copied. Note that copying a project that contains resource filters will not copy the resources that are filtered out. This may or may not be what the user expects. Copying filtered out resources would require removing resource filters on the project, which could cause unexpected performance and scalability problems that the resource filters were addressing in the first place.
Since Szymon is in vacation, John, can you review the latest fix please? Thanks,
Created attachment 176100 [details] Alternate fix (same tests) For the move bug, maybe I am misunderstanding but it looks like Serge's patch could leave the .project file unwritten in some cases. This patch has a simpler fix that just sets the "overwrite" flag when copying the metadata for .project. That way, if the earlier code had to write the .project, this will simply overwrite the metadata in the tree and not fail. For the copy bug, the fix looks good. The problem is that when copying we create a new description by cloning the old one. Cloning loses data such as filters, links, etc. Links get recreated anyway during the copy, but filters are never copied. My patch just adds a comment about this next to the fix.
Ok, that looks good to be, this is now fixed on head.
Verified on I20100912-2000. Project can be renamed even if the given filter exists.
