Community
Participate
Working Groups
Both symlinks and linked resources can cause aliasing of multiple resources to the same file in the filesystem, so org.eclipse.core.internal.resources.AliasManager should track symlinks as well as linked resources. This bug arose from bug 44107.
Can you give a concrete example, where it would be beneficial that AliasManager knows about the alias introduced by a symbolic link? Such that a JUnit test could be written against that example?
(In reply to comment #1) > Such that a JUnit test > could be written against that example? It's easy to write a JUnit test. Make a project "proj" and inside it, a folder "foo" and a symlink "bar" -> "foo". Create "/proj/foo/file" using the Resources API and then test whether the Resources API knows that "/proj/bar/file" exists. > Can you give a concrete example, where it would be beneficial that AliasManager > knows about the alias introduced by a symbolic link? Arguing that it is beneficial is slightly more work, but I could envision this scenario. A user has a project L containing the source for a C library and a project P containing a program that uses the library. P contains a symlink to L so that the build system of the program can find the library. The user sets up the CDT builder for P to autobuild on any change in P. When the user modifies a source file in L through Eclipse, she wants the autobuild to be triggered by virtue of the source file's visibility through P. That was a simple example. A user might have a much crazier development environment consisting of lots of nested projects with spaghetti symlinks, and it would be important for changes through one symlink to be immediately noticed and visible through the others to avoid confusing the user or the autobuild hopelessly.
Created attachment 89235 [details] Test
We don't have plans to address it during 3.4. However if someone takes this up, it would be appreciated. Martin? ;-) Anyway I've just attached a JUnit test based on the description from the comment #2, to speed it up.
Not exactly my area of expertise... Matt?
I don't see myself getting around to implementing this anytime soon.
I think I'll look at this in the context of bug 233939.
I'm decoupling bug 233939 from this one, since it is really interested in a simpler case which can be fixed without full tracking of symbolic links. We'll use this bug for investigating full tracking of symbolic links in the workspace as per bug 233939 comment 9 and onwards.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
