Community
Participate
Working Groups
If a link with no target exists on disk, then file#exists returns false but the link does exist (i.e. has a target). If such a link is moved, the move method in LocalFile throws an exception because neither the source or destination exists.
I should add that by "no target" I mean a link with a target that doesn't exist.
Sorry for being dense, but I'm not clear on what's failing. What do we believe is the *correct* behavior here? Is it, "If the link target exists, move the target to the new location, otherwise move the link itself"? (That seems odd to me, although if that turned out to be the way the operating systems do it, I'm ok.)
(In reply to comment #2) We are allowed to move symlinks >only< if they are linked to existing targets. Otherwise we'll get an exception.
Actually, what happens is that, if a move is performed through the local EFS on a dead link (i.e. a link whose target doesn't exist), the link gets moved and then the EFS move code checks whether the target exists and throws an exception because it doesn't (i.e. the move works but throws an exception). The post-move exist check in LocalFile needs to check both for existence and, if the files doesn't exist, it needs to look for a link as well.
(In reply to comment #2) > if that turned out to be the way the operating systems do it, I'm ok. I think you have to be ok then: $ mkdir x $ cd x $ ln -s /not/existing foo $ ls -l total 1 lrwxrwxrwx 1 mober wrs 13 Oct 20 12:58 foo -> /not/existing $ mv foo bar $ ls -l total 1 lrwxrwxrwx 1 mober wrs 13 Oct 20 12:58 bar -> /not/existing I think I have noticed this "behavior" of EFS a while back but I cannot remember whether I filed a bug back at that time. In RSE, I am pretty sure we can move broken symlinks properly. Michael, under what circumstances do you notice this problematic behavior? If I am not mistaken, broken symbolic links are not even shown in the Eclipse Workspace, so your use-case must be somewhat special?
Our SCM supports both Eclipse based resources and non-Eclipse based resources. For non-Eclipse resources, we use EFS to access the file system since it has additional native support. We had to write our own native for creating symbolic links but, other than that, EFS provides everything we need. Given that the move succeeds, the work around is fairly straight forward. We catch the exception and check to see if the move succeeded. If it did, we ignore the exception.
Yes, the move actually works in EFS, but then we do a post-condition check to make sure the destination exists and that's when we fail. I think this post-condition just needs to be improved (use our own native file info rather than just calling java.io.File#exists(), which returns false for broken links).
(In reply to comment #6) > We had to write our own native for creating symbolic links What about contributing that back to Eclipse? I'm sure you did it very well.
(In reply to comment #7) Since this fix is required for 3.5.x, we should only improve the post-condition here. Pawel's work on bug 290318 is probably too big to backport it to the maintenance streams.
Contributing the natives back to Eclipse is certainly something we should think about. Unfortunately, there are several factors that make that unlikely in the near future (e.g. we have many high priority issues on our plate at the moment).
Created attachment 150366 [details] Patch_v01 Patch_v01. I haven't tested it thoroughly yet.
Created attachment 150380 [details] Patch_v02 JUnit updated. I tested it on Red Hat EL AS 4 and it works fine.
Thanks Pawel. Released to HEAD. Please open a bug to backport the fix to 3.5.2.
(In reply to comment #13) > Thanks Pawel. Released to HEAD. Please open a bug to backport the fix to 3.5.2. Done, it's bug 293302.
