Bug 14320 - copy fileset followsymlinks="false" does not copy symlinks at all
Summary: copy fileset followsymlinks="false" does not copy symlinks at all
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.5
Hardware: All Linux
: P3 enhancement with 2 votes (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-06 23:45 UTC by Eddie Ruvinsky
Modified: 2010-07-13 11:43 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eddie Ruvinsky 2002-11-06 23:45:05 UTC
When I copy a fileset that has followsymlink="false" any symlinks encountered 
in the fileset get excluded.  This seems like the wrong behavior, as I would 
expect the symlink to get copied as-is (in its symlink form) -- e.g., 
emulating "cp -a".
Comment 1 Gus Heck 2002-11-07 04:00:52 UTC
I presume OS should be set to one of the *NIX's? Please change it to your 
platform?

The reason for this behavior is that Java doesn't really have a concept of 
Symlinks. The key reason for followSymlinks was in reference to bug 1550 where 
the problem was that delete tended to go places it shouldn't without this 
atribute. 

There is no way to find out exactly what a link is. Symlinks are a unix 
specific OS feature, so because Java is supposed to be relatively platform 
independant, no means for this is provided. 

What can be done (in things like my recently submitted symlink task) is a 
careful comparison involving the difference between getAbsolutePath() and 
getCannonicalPath. This gives you ONE possible definition of a link to the 
resource in question. It does NOT give you the exact link that exists on the 
filesystem. What you get is an absolute version of the link. 

You can find detailed discussion in bug 1550.

Any relative links such as one in /home/gus/somedir

foo->../bar.txt 

will get converted to 

foo->/home/gus/somedir/bar.txt

by this method. So even if Ant tries to implement some form of link copying, 
it will completely mangle any relative links. I suspect you wouldn't be 
satisfied with this?

If you are willing to write a platform dependant build file, you can use the 
Apply task with the executable set to cp and passing an argument of -a to 
acheive an exact duplication of the "cp -a" behavior :).

If you want platform independance, you probably have to sacrifice platform 
specific features like symlinks.
Comment 2 Gus Heck 2002-11-07 04:03:07 UTC
oops messed up my example. 

foo->../bar.txt

would get converted to

foo->/home/gus/bar.txt

The point is still the same however.
Comment 3 Eddie Ruvinsky 2002-11-07 06:00:42 UTC
Hi Gus, thanks for the prompt response.  Yes, I was afraid of that.  To work 
around this issue, I have my ant script invoke "make" in a subproject that 
takes care of doing the OS-specific functionality (creates the symlink in the 
build directory).

You guessed it -- my symlink is relative, and I'd like it to stay that way 
after a build.

The reason why I thought this was a bug is because it didn't seem like the 
expected behavior (since it wasn't documented as such) when 
followsymlinks="false".  I wouldn't expect it to exclude all symlinks as a 
consequence.

Needlesstosay, although symlinks are not platform-independent, one can argue 
that since there are useful core ant tasks such as "Chmod" that only take 
effect under Unix, supporting symlinks as an *option* (e.g., when copying) 
should be strongly considered.

Thoughts?
Comment 4 Gus Heck 2002-11-07 15:57:09 UTC
Hehe you don't need to sell me on the value of platform specific tasks. I wrote
the Symlink task (committed to 1.6 alpha yesterday) and have also written a
chgrp and chown which should get commited soon. I might at some point work on
symlink support within the copy task, but first I intend to expand my symlink
task so that the user can provide information that answers the question
"relative to what directory?", and get a relative link.

You do make a reasonable point about clarifying the effects of followSymlinks. 
in retrospect a slightly better name might have been ignoreSymlinks (with
oposite atribute values of course), but the perspective at the time was that of
delete task rampaging through unintended sections of the file system.

To take another perspective, FileSets are collections of files, and symlinks
really arn't the same as files, so the current behavior is not inconsistant with
that idea. The problem comes in that people tend to think of anything in te
filesystem as a file. (which is a very nice way to think when it works). I am
also given to wonder what java (and therefore ant) does if it selects a named
pipe, or other funky unix fs object.
Comment 5 Eddie Ruvinsky 2002-11-07 17:58:40 UTC
Glad to hear you're working on support for symlinks in 1.6.

I understand the reasoning for adding in "followsymlinks" because of the file 
deletion operation.  It's not clear as to whether or not symlinks should 
definitely be treated as files.  I'd suggest that both filesets and dirsets can 
be aware of symlinks and can offer the same kinds of symlink options when file 
operations are performed on them.

I also agree about renaming "followSymlinks" to "ignoreSymlinks" 
(or "excludeSymlinks") and swapping its boolean value semantics (and default 
value).
Comment 6 Gus Heck 2002-11-07 19:11:49 UTC
Well, followsymlinks is already in a released stable version, so it won't get
renamed. That would break existing build files which is bad bad bad. 

As for making FileSet and DirSet "aware" of symlinks, I am not sure what you
mean, but I presume it is something like storing the link name and the name of
the resource referenced such that it can be reproduced. If you think carefully
about what I have said here, you will realize that this would not be very
sucessful due to the absolutization (is that a word?) problems. Even if it could
be done that would add a lot of checks for which OS, and a fair bit of overhead
on supported OS's to the most used part of ant. I am not sure it would be worth
the performance cost (for most users).

This now looks like an enhancement request to me, do you agree?
Comment 7 Conor MacNeill 2003-02-05 13:25:33 UTC
So, what next is required on this? Changing to enhancement as suggested in the
last message.
Comment 8 Gus Heck 2003-02-05 15:40:27 UTC
I can imagine that one could add an atribute that caused an OS check and if we
it is a *nix set a flag that caused copy to use FileUtils.isSymbolicLink to
identify symlinks. ymlinks could then be reproduced in either absolute form or
minimum relative form or not reproduced in the destination directory based on an
atribute such as copySymlinksAs="none"|"absolute"|"minRelative"

I don't know how much time I can put into it, but I'd be willing to try that if
it sounds like a good idea to anyone else.