Hi,
The FTP task (or more likely commons-net) definitely works in mysterious ways (log files don't tell much). I use it to FTP to various servers (windows/? and linux/wu-ftp) and what I have seen is that you have to set up the task differentlty for different types of servers and ftp servers -- by trial and error :(
Generally, for linux the following works for me:
<target
name="promote-remote-ftp"
description="blah blah">
<ftp
depends="yes"
action="send"
verbose="yes"
remotedir="${project.domain}"
server="${lsb.ftp.host}"
userid="${lsb.ftp.username}"
password="${lsb.ftp.password}">
<fileset dir="${project.stages.stage.qa}"/>
</ftp>
</target>the above won't work if I set the @timediffauto to true (even though the user has write access) -- one file gets sent and then hangs on the second.
I have also tried the modified selector for the fileset (since it doesn't rely on remote files). This fails on linux (I forget the error -- something like command not supported). But using the modified selector with a windows server does work.
For windows, even though I have write access, I can't use the @depends=true, but can use the modified selector:
<target name="promote-remote-ftp" description="blah blah"> <ftp action="send" verbose="yes" remotedir="" server="${project.ftp.host}" userid="${project.ftp.username}" password="${project.ftp.password}"> <fileset dir="${project.stages.stage.dev}"> <modified update="true" seldirs="true" cache="propertyfile" algorithm="digest" comparator="equal"> <param name="cache.cachefile" value="${cache.properties.file}"/> <param name="algorithm.algorithm" value="MD5"/> </modified> </fileset> </ftp> </target>
best, -Rob
Pierre Grimaud wrote:
Hi everyone,
First of all, many thanks for the great team and the outstanding product (ant!) it delivers for now quite a while. What would I do without ant, I have no clue, but certainly a little less.
Anyways... I recently changed my production environment for my personal website so now I have to push files over FTP (across the internet) instead of a shared network drive. I had a quick look at the FTP task and was pleased as it seemed to address all that I needed and some more.
After a few days of testing and looking at some forums, it appears I cannot use it productively as of now, for a number of reasons, all of which I am willing to investigate and fix, to the best of my abilities of course.
This email is an attempt for a first contact with the Ant developpers community, in order to figure out :
1. how to submit a patch,
2. how to work with the latest (to ensure that my patch could be integrated in the build without versioning and merging nightmares),
3. To make sure no one is working on those same problems, making my efforts effectively useless.
Well, I hope I will get an answer to all three of these questions with this email. Disclaimer: I haven't had a look at the source code yet.
Let's now get to the core of my problems with the optional FTP task:
1. After transferrig a few files, the FTP task usually fails with one of the two messages:
1a. [SocketException: Connection reset]. I know that the timeouts on my ftp server are quite aggressive (1 min), but I have never had any problems with any of the FTP clients I have ever used, but for Ant's, possibly indicating a possible improvement.
1b. [could not put file: 500 ORT not understood]. This one obviously looks like a communication problem, but for the fact that it never happens on the same file or at the same time. Again, it is the first time I see that message, after some long month of interactnig with my server with other ftp clients.
All of these problems could be partially fixed by defining an "auto-retry on fail option", although it wouldn't really address the bugs and it would worsen the following problem quite a bit.
2. The transfer (with the depends="yes" option) is still extremely slow. This is of course due in part to my 128k DSL upload capabilities, but what I have seen in the debug mode seems to indicate that it still could be improved. I will now switch to pure speculation mode. The timestamp check for a file takes around 1 second on my machine, making the entire task pretty sluggish as I have hundreds of files. Instead of checking the timestamp one file by one file, it should be possible to get all the timestamps directories by directories, avoiding unnecessary roundtrips. Of course, this should be optional as it could actually worsen the performance on some cases.
Oh well, I will stop here for today and will ask the community if any of these problems are known, or acknowledged, or even in the process of being fixed. If not, I will be happy to proceed.
Thanks again for the great tool.
Pierre GRIMAUD [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
