My first reaction is that you have 3 processes running FTP trying to authenticate to the remote server, each with all of their commands buffered up when your script runs ahead and deletes all of the files. A short while later, each FTP process gets authenticated and reads the commands from the input buffer and can't access the files that have already been deleted.

The only thing that makes me think this shouldn't be the case is:

    close (CMD);
[download]

But this is indented differently than the rest of your script so perhaps you added that to the posting but it isn't actually in the code that is causing you problems.

You see, an explicit close on a file handle to a piped command also waits for the subprocess to exit. So the presence of that code should make what I described very unlikely.

My second reaction is "Don't you ever check for failure?!" I can almost excuse a quick hack missing some checks for failure. But once that quick hack starts not working the way you expected, one of the first things you need to do is add any checks for failure that you left out at first. Well, you left them all out:

sub fail {    # Allow failures to show on the web page.
    print @_;
    exit 0;
}
foreach $wmlfile (@fileftp)
    {
      if(-f $wmlfile)
      {
        $ftp_commands =
    "   open $remotehost1
            user $remoteuser $remotepass
            cd $remotepath
        asc
        put $wmlfile
        bye
     ";
         open (CMD, "|$cmd")
           or  fail "Can't fork() to run $cmd ($wmlfile): $!\n";
         print CMD $ftp_commands
           or  fail "Can't write commands to $cmd ($wmlfile): $!\n";
         close (CMD)
           or  fail "$cmd ($wmlfile) failed? ($?): $!\n";
         print "File $wmlfile has been transferred \n";
         print "<br>\n";
         $finish = 'transfer';
         copy ($wmlfile,"./$finish/$wmlfile")
           or  fail "Can't save $wmlfile to $finish: $!\n";
         }
      }
[download]

The error message for close failing is a bit ambiguous because it failing could mean the subprocess returned a non-zero status or it could be some error in the parent process such as not being able to flush some buffered input (thought the subprocess failing seem by far the most likely reason in this case).

Update: I've replaced the calls to die so that the errors would be visible on the web page, since this is a CGI script.

        - tye (but my friends call me "Tye")