----- Original Message ----- From: "Gus Heck" <[EMAIL PROTECTED]> 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? > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=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. *** <GUS> 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. symlinks 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. </GUS> <ANTOINE> 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 </ANTOINE> 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 preservesymlinks/copysimlinks="none"|"absolute"|"minRelative" <AFAIK> <ANT> 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 </ANT> <WINDOWS> .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 </WINDOWS> <UNIX> the area where symbolic links support should be least problematic, except for possible exceptions due to media not accepting symbolic links </UNIX> </AFAIK> 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. Antoine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
