develooper Front page | perl.perl5.porters | Postings from July 2019

Re: "Damaged tar archive" for perl-5.32.2 on ftp callsfromCPANmirrors

Thread Previous | Thread Next
From:
Niko Tyni
Date:
July 25, 2019 19:06
Subject:
Re: "Damaged tar archive" for perl-5.32.2 on ftp callsfromCPANmirrors
Message ID:
20190725190557.GA8364@estella.local.invalid
On Fri, Jul 26, 2019 at 01:49:06AM +1000, sisyphus wrote:

> With ftp.pl in its original form, I always saw output of:
> 150 Opening BINARY mode data connection for perl-5.31.1.tar.gz (17593158
> bytes)
> and thought that meant that I was, in fact, downloading in binary mode.
> Apparently that's not correct. What does that output actually tell me ?

That part looks weird indeed. It actually says BINARY mode even when
specifically requesting ASCII mode. Guess it's a bug in the server code.

> The next question is "Is it fair enough that the mirrors.rit.edu server
> requires this of my script ?"
> Since binary() is a method that's called on the Net::FTP object I would
> have expected that calling $ftp->binary() could be done at any time after
> initialization of $ftp.

Seems fair enough to me, particularly as binary() is returning false
when it fails. Net::FTP is just wrapping protocol commands here.

> Also, note that the ftp.funet.fi server has no such requirement. The script
> output reveals that on the ftp.funet.fi server the switch to binary mode is
> made *after* the login, even though the script calls the binary method
> *before* the login.

Not sure how you see that the switch is made after the login.
AFAICS it's sending 'TYPE I' and getting 200 (OK) before USER in your
script output.

But it looks like ftp.funet.fi uses binary mode anyway (even if ASCII mode
is specifically requested!) so there's no actual mode switch involved.
-- 
Niko, who thinks FTP is long obsolete and should just die...

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About