Re: Size bug in wget-1.7

2001-08-21 Thread Ian Abbott

On 17 Aug 2001, at 11:41, Dave Turner wrote:

> On Fri, 17 Aug 2001, Dave Turner wrote:
> 
> > By way of a hack I have used the SIZE command, not supported by RFC959 but
> > still accepted by many of the servers I use, to get the size of the file.
> > If that fails then it falls back on the old method.  The patch is
> > attached, in what I hope is an acceptable format.
> 
> Guess who forgot the attachment?  Sorry!

Nice patch. I think it can be improved by only sending the SIZE command 
if the file already exists (has a non-zero size, i.e. restval parameter 
in function getftp is non-zero).

I have attached a slightly modified version of Dave Turner 
<[EMAIL PROTECTED]>' s patch to add the non-zero restval test, 
remove an unused variable 's' from function ftp_size, and I have 
created the patch using the command cvs diff -uR to make it relative to 
the current CVS sources for wget-1.7.1-pre1.

Here is a ChangeLog entry for it:

2001-08-21  Dave Turner <[EMAIL PROTECTED]>

* ftp-basic.c (ftp_size): New function to send non-standard SIZE
  command to server to request file size.
* ftp.h (ftp_size): Export it.
* ftp.c (getftp): Use new ftp_size function if restoring
  transfer of a file with unknown size.



 wget-1.7.1-pre1-size-fix.patch


Re: Size bug in wget-1.7

2001-08-21 Thread Dave Turner

On Tue, 21 Aug 2001, Ian Abbott wrote:

> Nice patch. I think it can be improved by only sending the SIZE command
> if the file already exists (has a non-zero size, i.e. restval parameter
> in function getftp is non-zero).

Yep, good plan, like it.

> I have attached a slightly modified version of Dave Turner
> <[EMAIL PROTECTED]>' s patch to add the non-zero restval test,
> remove an unused variable 's' from function ftp_size, and I have
> created the patch using the command cvs diff -uR to make it relative to
> the current CVS sources for wget-1.7.1-pre1.

Many thanks, Ian.  I just realised there's another minor bug in the patch:
I think the ./configure script ought to check for  and behave
sensibly if it doesn't exist.  I'm afraid I don't know much about
autoconf: Learning it is on my TODO list, but so is climbing Everest...

-- 
Dave Turnerhttp://linux.clare.cam.ac.uk/~dct25
[EMAIL PROTECTED]   +44 7773 784486 (Orange)

Quidquid latine dictum sit, altum viditur [Quotes in Latin sound profound]




Re: Size bug in wget-1.7

2001-08-17 Thread Dave Turner

On Fri, 17 Aug 2001, Dave Turner wrote:

> By way of a hack I have used the SIZE command, not supported by RFC959 but
> still accepted by many of the servers I use, to get the size of the file.
> If that fails then it falls back on the old method.  The patch is
> attached, in what I hope is an acceptable format.

Guess who forgot the attachment?  Sorry!

-- 
Dave Turner
[EMAIL PROTECTED]

 wget-1.7-size-fix.patch.gz


Re: Size bug in wget-1.7

2001-08-17 Thread Dave Turner

On Wed, 15 Aug 2001, Dave Turner wrote:

> Not sure if this is wget's fault or a broken server, but it happens on a
> lot of servers so maybe it should be handled better.

It's not a broken server per se, but inconsistencies in server
implementations.  After a REST some servers respond to RETR with 150
 ( bytes) where  is the total filesize (as expected by
wget); others respond with only the remaining filesize, and there is no
direct way of differentiating the two.

By way of a hack I have used the SIZE command, not supported by RFC959 but
still accepted by many of the servers I use, to get the size of the file.
If that fails then it falls back on the old method.  The patch is
attached, in what I hope is an acceptable format.  This is my first
bugfix, but

tar -zxf wget-1.7.tar.gz
gunzip -c wget-1.7-size-fix.patch.gz | patch -p0

works here.  HTH,

-- 
Dave Turner
[EMAIL PROTECTED]




Size bug in wget-1.7

2001-08-15 Thread Dave Turner

Not sure if this is wget's fault or a broken server, but it happens on a
lot of servers so maybe it should be handled better.

The bug seems to manifest itself when resuming an FTP transfter and the
length is unauthoritative.  The reported total length is in fact the
remaining length (i.e. the total length minus the length downloaded); the
reported remaining length is the total length minus twice the length
downloaded, which goes negative once you've downloaded 50% of the file!
For example, the actual size of kdebase-2.2.tar.bz2 is 10917131 bytes, and
this is what my log says when the transfer was resumed at 56%:

--11:38:44--  
ftp://ftp.sourceforge.net/pub/mirrors/kde/stable/2.2/src/kdebase-2.2.tar.bz2
   => `kdebase-2.2.tar.bz2'
Connecting to ftp.sourceforge.net:21... connected!
Logging in as anonymous ... Logged in!
==> SYST ... done.==> PWD ... done.
==> TYPE I ... done.  ==> CWD /pub/mirrors/kde/stable/2.2/src ... done.
==> PORT ... done.==> REST 6131968 ... done.
==> RETR kdebase-2.2.tar.bz2 ... done.
Length: 4,785,163 [-1,346,805 to go] (unauthoritative)

  [ skipping 5760K ]
 5760K   131% @   2.07 KB/s

As an artefact of this bug, the percentage downloaded is also incorrect
(also shown here)

Yours,

Dave Turner
[EMAIL PROTECTED]