Re: Size bug in wget-1.7
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
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
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
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
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]