ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Levy-Lambert" <>
Subject Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net
Date Tue, 12 Aug 2003 16:39:02 GMT

----- Original Message -----
From: "Gus Heck" <>
Sent: Tuesday, August 12, 2003 4:10 PM

> Antoine,
> Since you have recently been playing with symlinks/FTP what are your
> thoughts on bug 14320?

First the bad news : I do not have the time to work on this in the frame of
ant 1.6. I am concerned that this might open a large Pandora box. :-(

Once ant 1.6 is released, I would like to discuss again the topic of
"Resource(s)" and/or Jakarta-Common VFS. I would like to evaluate the use of
Jakarta-Common VFS in ant, so that ant does not need to reinvent the wheel
for everything. Just a thought at the moment, might be wrong.

Then concerning bug 14320 specifically :

Changing followsymlinks="false" to preserve symbolic links as symbolic links
would be a breach of behavioral compatibility, not fixing a bug.

The implemented semantics of followsymlinks="false" is like an exclude of
the symbolic links ***and*** of the files and directories pointed to by the
symbolic links if they are not "covered" by another include pattern which
does not use the link.

*** The DirectoryScanner and the tasks that use it (nearly everything that
deals with filesets in ant, or maybe 80% of ant) do not contain any
provision to manipulate symbolic links as links. ***

If the user chooses the option followsymlinks="true" in the fileset
definition, which in turn gets transmitted to the fileset in
AbstractFileSet#getDirectoryScanner(Project p), the files and/or directories
*** pointed to by the links *** (not the links themselves ) are manipulated
by the task using FileSet/DirectoryScanner.

The symbolic links *** as such *** are never manipulated on the target side
of a task that I know of (except symlink of course).

Manipulating the symbolic link as a link is doable in a portable way for
packaging tasks (zip, jar, war, ear, tar). I am not sure what is the API to
find the target of the symbolic link (do an exec of ls -L and read the
result, or go the JNI route ?) ...

*** We need another attribute for filesets and directoryscanner called
preservesymlinks. ***
I can imagine that one could add an atribute that caused an OS check and if
it is a *nix set a flag that caused copy to use FileUtils.isSymbolicLink to
identify symlinks. symlinks could then be reproduced in either absolute form
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
it sounds like a good idea to anyone else.
Does "minRelative" mean relative to the root dir of the fileset ?
Maybe "asis" would be a good option too, to copy somelink -> ../../foo/bar
as ../../foo/bar

This attribute would only be legal with followsymlinks="false" (since true
means manipulate the objects pointed to by the links).

Then we need to define task by task how to use
Symbolic links do not exist in Windows (for ant's FileUtils#isSymbolicLink)
Symbolic links can be created via the symlink task, which relies on ln -s
available in the operating system
.lnk files exist
non .lnk links exist
not aware of command line utility distributed with all versions of the OS to
do this
aware of ln.exe in cygwin
aware of shortcut.exe, a program which is part of the Windows NT resource
kit of Microsoft
the area where symbolic links support should be least problematic,
except for possible exceptions due to media not accepting symbolic links

Apart from <copy/>,  packaging tasks are good candidates for having the
option of copying/preserving symbolic links. They would only be impacted if
they run on UNIX.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message