Thanks, I looked there. It doesn't seem to help much though since I need to "push" files and LWP::Parallel only allows me to "pull" them.

I guess I'll do it completely different at last. I'll zip the files up, upload the zip and then a 0B "done flag" file and run another service on the other side that'll take the ZIP and unpack it. It'll be quicker and safer anyway, that way I can

• extract into TEMP
• delete old
• move new

If anyone has a nice solution for the async FTP I am still interested though :-)

  Jenda@Krynicky.cz

Here's a suggestion for the way you're doing it right now: upload with a bogus filename, then send RNFR BOGUS.ZIP and RNTO TARGET.ZIP. No 0 byte file kludges here..

Makeshifts last the longest.

Yes I could do it that way. I think I'll still use the 0B file though.

The "unzipper" service will use Win32::ChangeNotify to monitor a directory without having to read it every now and then ... thus the service will take no processor time at all if you do not upload anything. The monitored directory will NOT be the one into which I upload the ZIPs ... it'll be a subdirectory of that one. So the service will stay sleeping while the FTP server creates and fills the ZIP file and be waked up by the 0B file after the ZIP is done.

Actually I might find out I do not need to do that and that I will be able to filter the notifications so that the service will not be notified everytime a next chunk of the file is uploaded, but I doubt it.

Thanks for the suggestion anyway :-)

Update 2003-04-29: Just FYI. In the end I used something similar to the 0B file idea. The file is not actually 0B, it's a little bigger. It contains an MD5 hash of the ZIP and some secret text. The Unzipper then computes such an MD5 hash itself and compares the two to make sure the ZIP was uploaded by the Uploader. We use these two services a lot and are quite happy with the solution.

  Jenda