[16531] in Athena Bugs
Re: kerberized ftp hash mode.
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Thu Dec 3 18:13:36 1998
Date: Thu, 3 Dec 1998 18:13:26 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Bill Cattey <wdc@MIT.EDU>
Cc: bugs@MIT.EDU, linux-dev@MIT.EDU
In-Reply-To: Bill Cattey's message of Thu, 3 Dec 1998 04:30:00 +0000 (),
<AqNVD8Bz0001I1cEgY@mit.edu>
Date: Thu, 3 Dec 1998 04:30:00 +0000 ()
From: Bill Cattey <wdc@MIT.EDU>
Being paranoid, I often when using ftp via PPP tell it to go into hash
mode where it prints a '#' after so many bytes are transferred.
I thought the new Kerberized FTP was broken because when transferring
large files, all I would see would be a zero length file on the receive
side, and no hash marks.
I see now that if I wait until the ENTIRE transfer is done, ALL the has
marks print, and there's the file, nice as you please.
This is NOT a good implementation of hash mode.
This problem only occurs if you are transfering files in secure mode,
and it happens because the gss-ftp/gss-ftpd is protecting the data
transfer in large chunks, and the hash mark is getting printed not as
bytes are getting read from wire by "secure_getc()", but in the routine
that calls secure_getc(), which blocks until the entire protected
subchunk has been received.
You can see this if you download a 2 megabyte file; it will pause for a
while, print out roughly half the hash marks very quickly, pause again,
and then print out the rest of the hash marks.
Unfortunately, secure_getc() is used by more than just the data channel,
so fixing this will require either (a) changing some abstractions, or
(b) breaking said abstraction variables with some ugly global varaible
hacking. Since there isn't an easy fix, and this is (IMHO) an aesthetic
issue, I don't plan to spend a lot of time personally fixing this.
If someone wants to work on it, they're welcome to, but please send us a
clean fix if you're expecting us to take it back into our source tree.
- Ted
