Community
Participate
Working Groups
build 3.1 RC3 We need to investigate the behaviour of: IWorkspaceRoot#findFilesForLocation IWorkspaceRoot#findContainersForLocation In FileSystemResourceManager#allPathsForLocation we check the user-specified path to see if its a prefix of the project location to determine if that resource can live inside the project. But if the project contains a symbolic link and the user-path is the real path, it will not be found. For instance, if we have: /workspace/myProject/aaa -> link to /tmp/bbb then findFilesForLocation("/tmp/bbb") shouldn't be empty See also bug 100807. We need to determine if this is a regression from 3.0 or not.
Created attachment 23664 [details] test case Here is a test case for the problem. I have confirmed that it is a problem in 3.0 as well and not a regression for 3.1.
Is someone requesting that we support this? I don't think we really want to support tracking *back* across symbolic links. It would require checking the supplied path against a canonical representation of all project and linked resource locations. I'm inclined to mark WONTFIX...
See bug 100807 and talk to Darin. :-)
Ok, this is really a side-effect of 43623 then. Since find*ForLocation methods do not perform case-insensitive lookup, they converted the paths to canonical representaion (java.io.File.getCanonicalPath()). Getting a canonical path does resolve case variants, but it *also* resolves symbolic links, which was an unintended side-effect. The workspace operates fine with *nix symbolic links as long as you "maintain the illusion" and always use the links consistently. As soon as a client resolves a symbolic link, it now appears to be a completely different path. We have never attempted treating *nix symbolic links as equal to their canonical form, and doing so would be a considerable effort. Fixing find*ForLocation wouldn't be too hard (although it would add speed/space cost), but that's only a small part of the story. For example, if you modify an IFile that has a duplicate due to a symbolic link, the resource delta would need to contain all duplicate files as well. We handle this for IResource links, but not for symbolic links.
