I can get ANT to download a file from an FTP server. I can get it to download a file if it is a hard link to a file. If it is a symlink it will not download the file. It does not generate an error, it simply does not see it as a file. <target name="explosivo-log"> <ftp action="get" server="explosivo.com" userid="xxxx" password="xxxx" binary="no" verbose="yes" remotedir="/home/explosivo"> <fileset dir="/www/logs" followsymlinks="yes" defaultexcludes="no"> <include name="explosivo-access-log"/> </fileset> </ftp> </target> I have tried many permutations of followsymlinks and it still never seems to see the files I want...
This is because you are not looking at a unix filesystem when you use FTP task. Effectively you are looking at an FTP filesystem. In order to make FTP task work over FTP and look like it is a regular filesystem, a custom inner class called FTPDirectoryScanner is implemented, extending DirectoryScanner. Since the basis of symlink detection, is the result of a comparision between carefully constructed File objects containing absolute paths vs. the results of file.getCannonicalPath() it may not be possible to propogate this feature into FTP task. It might be good to add a check to throw a build exception if follow symlinks gets set to true in FTP task though. (and a note about it in the docs of course. I think I will try to come up with a patch for that tonight.
ok I just remembered that true is the default for followsymlinks... so nothing needs to be done except perhaps mention this explicitly in the docs. Meanwhile I notice that several other classes are likely to be effected by this: [gus@draco ant]$ grep -r "extends DirectoryScanner" * taskdefs/optional/ide/VAJWorkspaceScanner.java:class VAJWorkspaceScanner extends DirectoryScanner { taskdefs/optional/net/FTP.java: protected class FTPDirectoryScanner extends DirectoryScanner { types/optional/depend/DependScanner.java:public class DependScanner extends DirectoryScanner { types/ZipScanner.java:public class ZipScanner extends DirectoryScanner {
Well let me rephrase that... Nothing need to be done unless we feel it is important that we do follow symlinks on FTP... Clearly Bill wants it, but this may be an issue of the default behavior of ftp vs the default behavior of the unix filesystem. I suppose if ftp get works on symlinks from the ftp command line it should work here too, but I can't remember if that works or not.
This does not mirror the functionality of command line FTP utilities which will download a symlink to a file. I finally had a chance to peek into the source code and found where the problem is... In org.apache.tools.ant.taskdefs.optional.net.FTP.java (Thanks for the tip Gus) For a symlink the FTPFile will return false for both isFile and isDirectory... These are the only flags that get checked, so anything that comes back as a symlink (isSymbolicLink = true) is not counted or looked at. Its easy enough to add in the code to include the symlink Just change: if (file.isFile()) { String name = vpath + file.getName(); to if (file.isFile() || file.isSymbolicLink()) { String name = vpath + file.getName(); Now this brings out another problem... Symlinks to a directory. These do not register as directories. You can get the linked to name by FTPFile.getLink() but this is string for the filename, not another FTPFile object. I am still working on it, and most likely will need to get a file object for the target to see if its a directory... If so, it may need to be followed depending on how the decend into directories is done... Any thoughts would be appreciated I would guess that pattern matching should only happen against the link name, not the target...
I am working on the ftp task right now, and I am interested in solving this bug too if I can.
This problem should be fixed in CVS now. It will be in the nightly build 2003-08-06 and later. I need to add a testcase to check that the fix works.
I have added a testcase showing resolution of this bug, I am now closing the report. Cheers.