in reply to Net::FTP Bad File Descriptor - Much Weirdness

A couple of things:

  1. Net::FTP does not place errors in $!. This variable is usually reserved for system error messages, not application errors. Consider using the message() and/or code() methods to get the last message returned by the FTP server. (Note: This isn't tested, but since Net::FTP inherits from Net::Cmd, I would expect this would work.)
  2. You're doing a size check after $ftp->get, second-guessing the success/failure response of the get() method. Is there a reason you're doing that? Have you ever had a situation where the file was apparently successfully transferred yet the sizes were different (implying a truncated download)? I'm kind of curious. This check seems redundant to me, but you may have experiences that really do show a problem (perhaps something that should be communicated to the Net::FTP authors). Note that I might anticipate different file sizes if you're transferring a file using ASCII mode between systems with incompatible newline conventions. This shouldn't be considered a failure.

Replies are listed 'Best First'.
Re: Re: Net::FTP Bad File Descriptor - Much Weirdness
by hibernian (Acolyte) on Dec 05, 2001 at 19:50 UTC
    Hi there,

    Both points were very helpful - particularly 1) which explains the odd "Bad File Descriptor" message which had me tearing my virtual (I don't have any) hair out.

    As for point 2), yes, I was having problems with files not uploading completely and yet get() would not return with an error, hence the size check. I know already that every file being downloaded is gzipped, therefore I specify the transfer to be binary mode, in which case, the size of the file reported by the ftp server remotely will match (on a successful transfer) the file downloaded.

    However, what did enlighten me was the failure of our back-up ISDN link to the remote server (we were using ftp over a VPN over the Internet). It transpires that the intructions were being sent over the Internet, and yet the data was being received via the ISDN link.

    Yesterday, the ftp client would connect but could not receive any data. Now I need wave a large stick at whoever configured the firewalls.

    I imagine this is where the problem of the short files is coming from - the ISDN linking is either timing out or falling over. Most irritating.

    Thanks again,

    -Gregor-

    -- Gregor Anderson, Edinburgh. http://www.deletia.org/

[reply]
      Still, get() should not be returning a true value unless the transfer was completed successfully (if you ask me). This sounds like a bug with Net::FTP. I might contact the author and describe what happened. It's possible that this is actually intended behavior, so that you can resume the FTP transfer later. But there must be a better way of determining this than checking the size of the file by hand. As I mentioned, an ASCII transfer makes no guarantee that the size of the file will be the same on one side as the other.

      Glad you got it figured out though.

[reply]

In Section Seekers of Perl Wisdom