From user42@zip.com.au

In Net​::FTP version 2.77, when doing a put() if there's an error from
read() it seems to be silently treated as normal eof, where I hoped it
would gives some sort of error.

I see the code notices an error from binmode(), or socket write() and
close(), and gives an undef return, but apparently not for read()
trouble.

The foo.pl below simulates a read error with a tied file handle.
I wonder if the $ftp->put() could return undef in this case.

Dunno if it should also carp() or $ftp->message() or whatever for such
local errors. Carp might be orright for interactive use, but from a
program you'd prefer to get a message or something and display it in
your own way. I suppose for compatibility any change to carp vs message
or $! etc might have to be just an option.

From user42@zip.com.au

foo.pl

From user42@zip.com.au

Flags:
    category=library
    severity=medium
    module=Net::FTP

Site configuration information for perl 5.14.2:

Configured by Debian Project at Sat Mar  3 16:40:46 UTC 2012.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
   
  Platform:
    osname=linux, osvers=2.6.32-5-686-bigmem, archname=i486-linux-gnu-thread-multi-64int
    uname='linux murphy 2.6.32-5-686-bigmem #1 smp mon jan 16 16:42:05 utc 2012 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Dldflags= -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.14 -Darchlib=/usr/lib/perl/5.14 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.14.2 -Dsitearch=/usr/local/lib/perl/5.14.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.14.2 -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='4.6.2', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib /usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=, so=so, useshrplib=true, libperl=libperl.so.5.14.2
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector'

Locally applied patches:

From @jkeenan

On Sat May 26 16​:44​:40 2012, kryde wrote​:

In Net​::FTP version 2.77, when doing a put() if there's an error from
read() it seems to be silently treated as normal eof, where I hoped it
would gives some sort of error.

I see the code notices an error from binmode(), or socket write() and
close(), and gives an undef return, but apparently not for read()
trouble.

The foo.pl below simulates a read error with a tied file handle.
I wonder if the $ftp->put() could return undef in this case.

So far I am unable to confirm the problem because I cannot get 'foo.pl'
to complete on either of two platforms at my disposal.

On Darwin/PPC, the program dies here​:

#####
Cannot connect​: Net​::FTP​: connect​: Invalid argument at 113390_foo.pl
line 24.
#####

On Linux/i386, the program dies here​:

#####
Cannot cwd​: /pub​: No such file or directory
at 113390_foo.pl line 30.
#####

Can you (or anyone) supply a different example?

Thank you very much.
Jim Keenan

The RT System itself - Status changed from 'new' to 'open'

From user42@zip.com.au

"James E Keenan via RT" <perlbug-followup@​perl.org> writes​:

Cannot cwd​: /pub​: No such file or directory
at 113390_foo.pl line 30.

You'll need an ftp demon with some writable directory to do a put() of
course. I ran up a local proftpd to try it.

From @jkeenan

On Sat May 26 16​:44​:40 2012, kryde wrote​:

In Net​::FTP version 2.77, when doing a put() if there's an error from
read() it seems to be silently treated as normal eof, where I hoped it
would gives some sort of error.

I see the code notices an error from binmode(), or socket write() and
close(), and gives an undef return, but apparently not for read()
trouble.

The foo.pl below simulates a read error with a tied file handle.
I wonder if the $ftp->put() could return undef in this case.

Dunno if it should also carp() or $ftp->message() or whatever for such
local errors. Carp might be orright for interactive use, but from a
program you'd prefer to get a message or something and display it in
your own way. I suppose for compatibility any change to carp vs message
or $! etc might have to be just an option.

Net​::FTP, as part of the libnet distribution, now is maintained on CPAN.
Accordingly, I have transferred this ticket to libnet's bug queue at
https://rt.cpan.org/Ticket/Display.html?id=88492.

Closing this ticket.

Thank you very much.
Jim Keenan

@jkeenan - Status changed from 'open' to 'rejected'