Re: IT Ticket 1636909 - FTP "size" problem

On Wed, Jun 29, 2005 at 01:54:50PM -0700, Gregory Hicks wrote:
> Gopi:
> 
> One of my customers believes that our wu-ftpd 2.6.2 ftp server is slightly 
> borken.
> 
> " When in binary mode (TYPE I), the server is *always* returning zero
> from the SIZE command.  I believe this is an error"

According to the uput you supply, this is not true.  Both of the pre-existing
files welcome.msg and axlxt.tgz return non-zero sizes, and presumably these
were in binary mode because you don't show the mode being changed before
xerox.asf is transferred and its size is queried.

So it would appear that the size is only zero when you query a file which
has just been transferred in the same session.

Looking at the source code, the daemon calls fclose() when it has finished
writing the file.  When it gets the size in binary mode, it calls stat() and
reads the st_size record in stat buffer, which also appears to be correct.
(In ASCII mode it actually opens and reads the file, counting the characters,
so that it can account for the fact that "\n" should be expanded to "\r\n",
which is why it behaves differently.)

I'm wondering if this is actually a problem with the operating system not
really flushing the output buffer and updating the inode when fclose() is
called, so that the status buffer returned by stat() is still 0.  Once the
ftp session is closed and a new one is opened, then the inode has been updated,
so the stat buffer is now correct.  Similarly, if the mode is switched to
ASCII without closing the ftp session after the file transfer, then since the
file data is actually being read, the character count would be non-zero.

Or perhaps the OS is caching the stat buffer in some way ?

According to my Solaris 8 man page, fclose() should force the file output
buffer to be written, but who knows if the underlying code in some OS is
still caching this or the stat buffer somehow.  I don't think it should be,
but this would be consistent the behaviour you are seeing.

If it isn't that, then I'm out of ideas; the code in sizecmd() looks
reasonable to me...

Cheers, Bob


> 
> I tried to isolate this and found that it, however, we restart the ftp
> connection, we can get the correct results (I think!  But I just
> noticed that the last set of data points is not in binary mode...):
> 
> ftp> quote size welcome.msg
> 213 2518
> ftp> cd pub
> ftp> quote size axlxt.tgz
> 213 4799355
> ftp> 
> ftp> send xerox.asf
> 200 PORT command successful.
> 150 Opening BINARY mode data connection for xerox.asf.
> 226 Transfer complete.
> local: xerox.asf remote: xerox.asf
> 961003 bytes sent in 0.28 seconds (3316.67 Kbytes/s)
> ftp> quote size xerox.asf
> 213 0
> ftp> quot size xerox.asf
> 213 0
> ftp> 
> 
> metis% ftp ftp
> Connected to ftp.
> 220 ftp FTP server (Version wu-2.6.2(1) Mon Feb 24 20:50:00 PST 2003)
> ready.
> Name (ftp:ghicks): ftp
> 331 Guest login ok, send your complete e-mail address as password.
> Password:
> ftp> cd pub
> 250 CWD command successful.
> ftp> quot size xerox.asf
> 213 966160
> ftp> 
> 
> Any thoughts?
> 
> Regards,
> Gregory Hicks
> -------------------------------------------------------------------
> Gregory Hicks                        | Principal Systems Engineer
> Cadence Design Systems               | Direct:   408.576.3609
> 555 River Oaks Pkwy M/S 6B1          | Fax:      408.894.3400
> San Jose, CA 95134                   | Internet: [email protected]
> 
> I am perfectly capable of learning from my mistakes.  I will surely
> learn a great deal today.
> 
> "A democracy is a sheep and two wolves deciding on what to have for
> lunch.  Freedom is a well armed sheep contesting the results of the
> decision." - Benjamin Franklin
> 
> "The best we can hope for concerning the people at large is that they
> be properly armed." --Alexander Hamilton
> 

-- 
Bob Luckin      [email protected]      "Coder, adapt; FTP Ada, redo C"