Debian Bug report logs - #24082
lynx: lynx fails to download entire file if file is large(?)

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: <bam@snoopy.apana.org.au>

To: submit@bugs.debian.org

Subject: lynx: lynx fails to download entire file if file is large(?)

Date: 30 Jun 1998 04:22:01 -0000

Package: lynx
Version: 2.8-1

When downloading a large file, lynx stops downloading after about the
first megabyte (exact amount varies each time, some files get up to 10
megabytes) and pretends that everything worked successfully (ie
no errors or warnings given, and the user-defined download menu
appears).

This has occured for me with past versions of lynx and squid, and is
not debian specific. At first I thought the problem was because the
link may have been congested at the time, but I know that transfers
were making satisfactory performance before they were aborted.

So far the only common elements I have been able to identify are:
- lynx
- HTTTP 1.0  (as well as FTP proxy through squid, which only seems to support
	HTTP 1.0)

Could this be a bug/limitation/feature of HTTP 1.0? I haven't been able
to test HTTP 1.1 (yet). Although I have never seen another browser
with the same problem.

The end of a -trace (nondebian system, with Lynx 2.6) gives:

Read 2252800 of 4064207 bytes of data.
Read 2255720 of 4064207 bytes of data.
Read 2258640 of 4064207 bytes of data.
Data transfer complete

lynx knows that the file size was 4064207 bytes, but yet it still stopped
at 2258640, for no good reason...

At the minimum it should have displayed an error to the user.

(BTW: This problem occurs without the use of a proxy server, and on two
completely seperate Internet connections).

At the moment, I don't have fast access to my debian system, but know
that version 2.8-1 had similar symptoms. Please let me know if you
want me to reproduce the trace using debian and/or show the complete
listing from above.

-- System Information
Debian Release: 2.0 (frozen)
Kernel Version: Linux snoopy 2.1.105 #2 Tue Jun 9 20:51:42 EST 1998 i486 unknown

Versions of the packages lynx depends on:
ii  libc6           2.0.7pre3-1    The GNU C library version 2 (run-time files)
ii  slang0.99.38    0.99.38-2.18   The S-Lang programming library, shared libra
ii  zlib1g          1.1.1-0.1      compression library - runtime

--- Begin /etc/lynx.cfg (modified conffile)
STARTFILE:http://snoopy.apana.org.au/
HELPFILE:file://localhost/usr/doc/lynx/lynx_help/lynx_help_main.html
DEFAULT_INDEX_FILE:http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/MetaIndex.html
LOCAL_EXECUTION_LINKS_ALWAYS_ON:FALSE
LOCAL_EXECUTION_LINKS_ON_BUT_NOT_REMOTE:FALSE
TRUSTED_EXEC:none
ALWAYS_TRUSTED_EXEC:none
TRUSTED_LYNXCGI:none
NNTPSERVER:localhost
http_proxy:http://snoopy.apana.org.au:8080/
https_proxy:http://snoopy.apana.org.au:8080/
ftp_proxy:http://snoopy.apana.org.au:8080/
gopher_proxy:http://snoopy.apana.org.au:8080/
news_proxy:http://snoopy.apana.org.au:8080/
newspost_proxy:http://snoopy.apana.org.au:8080/
newsreply_proxy:http://snoopy.apana.org.au:8080/
snews_proxy:http://snoopy.apana.org.au:8080/
snewspost_proxy:http://snoopy.apana.org.au:8080/
snewsreply_proxy:http://snoopy.apana.org.au:8080/
nntp_proxy:http://snoopy.apana.org.au:8080/
wais_proxy:http://snoopy.apana.org.au:8080/
finger_proxy:http://snoopy.apana.org.au:8080/
cso_proxy:http://snoopy.apana.org.au:8080/
no_proxy:snoopy.apana.org.au
NO_DOT_FILES:FALSE
MINIMAL_COMMENTS:TRUE
GLOBAL_EXTENSION_MAP:/etc/mime.types
PERSONAL_EXTENSION_MAP:.mime.types
XLOADIMAGE_COMMAND:
GLOBAL_MAILCAP:/etc/mailcap
PERSONAL_MAILCAP:.mailcap
COLOR:0:lightgray:black
COLOR:1:blue:black
COLOR:2:yellow:blue
COLOR:3:green:black
COLOR:4:magenta:black
COLOR:5:blue:black
COLOR:6:red:black
COLOR:7:magenta:cyan

--- End /etc/lynx.cfg

Message #10 received at 24082@bugs.debian.org (full text, mbox, reply):

From: "Christian Hudon" <chrish@debian.org>

To: bam@snoopy.apana.org.au, 24082@bugs.debian.org

Subject: Re: Bug#24082: lynx: lynx fails to download entire file if file is large(?)

Date: Fri, 3 Jul 1998 19:38:21 -0400

[Message part 1 (text/plain, inline)]

On Tuesday, June 30, bam@snoopy.apana.org.au wrote
> Package: lynx
> Version: 2.8-1
> 
> When downloading a large file, lynx stops downloading after about the
> first megabyte (exact amount varies each time, some files get up to 10
> megabytes) and pretends that everything worked successfully (ie
> no errors or warnings given, and the user-defined download menu
> appears).

Hi,

A couple questions:

Are you downloading through ftp or http?

I don't think HTTP/1.0 has anything to do with the problem, but squid might 
have something to do with it... Can you duplicate the problem without squid 
too?

Thanks,

  Christian

[Message part 2 (application/pgp-signature, inline)]

Message #15 received at 24082@bugs.debian.org (full text, mbox, reply):

From: Brian May <bam@snoopy.apana.org.au>

To: "Christian Hudon" <chrish@debian.org>

Cc: 24082@bugs.debian.org

Subject: Re: Bug#24082: lynx: lynx fails to download entire file if file is large(?)

Date: Sat, 04 Jul 1998 10:16:59 +1000

"Christian Hudon" wrote:
>A couple questions:
>
>Are you downloading through ftp or http?

Both. I haven't tried FTP without proxy though. I know that ftp by itself (eg 
ncftp) works fine.

>I don't think HTTP/1.0 has anything to do with the problem, but squid might=
>=20
>have something to do with it... Can you duplicate the problem without squid=
>=20
>too?

I once thought this might be the problem, too. So I disabled the proxy under
lynx and reproduced the problem. I verified lynx wasn't using the proxy in its 
trace output.

Recently, I found even Netscape has problems, too, so I don't know what is 
going on. I would have thought other people would have encountered the same 
problem. I haven't tested HTTP/1.1, but I probably should do so.

I have tested:
lynx + squid
lynx + no proxy
netscape + squid

And all of these combinations fail. The best answer I can come up with is that 
the transfer is slower then expected by the program (to me it looks OK, about 
10kb/s to 6kb/s reported by Netscape), and one end times out(?) and closes the
TCP connection with the local end assuming that means the transfer has
finished.

Although not desirable, I can understand why one end might time out. I don't 
like the fact though that no errors are reported.

Thanks for your response.

Brian May <bam@snoopy.apana.org.au>

Message #20 received at 24082@bugs.debian.org (full text, mbox, reply):

From: Klaus Weide <kweide@tezcat.com>

To: lynx-dev@sig.net

Cc: 24082@bugs.debian.org, Brian May <bam@snoopy.apana.org.au>

Subject: Silent read failures during transmission - patch

Date: Mon, 7 Dec 1998 23:32:26 -0600 (CST)

Here are some changes that were triggered by reading Debian bug report
#24082, see <URL:http://www.debian.org/Bugs/db/24/24082.html>.
This may or may not resolve the actual problem, but at least Lynx
shouldn't fail quietly.  I have not actually tested the changes with
any failing connections.
The significant changes are ifdef'd for Unix since I am unfamiliar with
e.g. the various VMS TCP stacks or the availability of errno.  So I left
things as they were for non-Unix to play it safe.
Some other changes to make the code more understandable (including
for myself).

    Klaus

Patches are against 2.8.1rel.2.  Eyeball inspection shows no significant
changes in the relevant sections of the latest devel code, so they
may also apply cleanly to 2.8.2dev.8.


* Check for EINTR from read() call in HTDoRead, and retry if necessary.
  This change only for Unix.  Interrupted read() system calls should be
  rare (or impossible, depending on the system implementation?) since 
  the read() is only done after a successful select(), but checking
  can't hurt.
* Check for read read() errors in HTDoRead and HTCopy, and generate
  alert messages for unexpected errors.  HTCopy still returns HT_LOADED
  to indicate success if any data have been received before an unexpected
  error or disconnection.  Previously this happened without any indication
  to the user that something was wrong and a document or file might be
  incomplete.  These changes currently only for Unix.
* Added/enhanced comments in HTFormat.c to document current behavior of
  HTCopy, HTFileCopy, HTGzFileCopy, HTParseSocket, HTParseFile, and
  HTParseGzFile.
* Moved definition of HT_NO_DATA to HTUtils.h, changed value of some
  status codes to libwww5-like values while we're at it.

*** lynx2-8-1.orig/WWW/Library/Implementation/HTAccess.h	Thu Aug  6 07:28:22 1998
--- lynx2-8-1/WWW/Library/Implementation/HTAccess.h	Mon Dec  7 20:37:39 1998
***************
*** 32,39 ****
  **      In general, positive codes are OK and negative ones are bad.
  */
  
- #define HT_NO_DATA -9999        /* return code: OK but no data was loaded */
-                                 /* Typically, other app started or forked */
  
  /*
  
--- 32,37 ----
*** lynx2-8-1.orig/WWW/Library/Implementation/HTFormat.c	Wed Sep 30 16:06:48 1998
--- lynx2-8-1/WWW/Library/Implementation/HTFormat.c	Mon Dec  7 20:37:41 1998
***************
*** 11,17 ****
  */
  
  #include <HTUtils.h>
- #include <HTAccess.h>
  
  /* Implements:
  */
--- 11,16 ----
***************
*** 530,535 ****
--- 529,555 ----
  **   CRLF at the end of lines which need to be stripped to LF for unix
  **   when the format is textual.
  **
+ **  State of socket and target stream on entry:
+ **  			socket (file_number) assumed open,
+ **			target (sink) assumed valid.
+ **
+ **  Return values:
+ **	HT_INTERRUPTED  Interruption or error after some data received.
+ **	-2		Unexpected disconnect before any data received.
+ **	-1		Interruption or error before any data received, or
+ **			(UNIX) other read error before any data received, or
+ **			download cancelled.
+ **	HT_LOADED	Normal close of socket (end of file indication
+ **			received), or
+ **			unexpected disconnect after some data received, or
+ **			other read error after some data received, or
+ **			(not UNIX) other read error before any data received.
+ **
+ **  State of socket and target stream on return depends on return value:
+ **	HT_INTERRUPTED	socket still open, target aborted.
+ **	-2		socket still open, target stream still valid.
+ **	-1		socket still open, target aborted.
+ **	otherwise	socket closed,	target stream still valid.
  */
  PUBLIC int HTCopy ARGS4(
  	HTParentAnchor *,	anchor,
***************
*** 597,602 ****
--- 617,637 ----
  		    rv = -2;
  		    goto finished;
  		} else {
+ #ifdef UNIX
+ 		   /*
+ 		    *  Treat what we've received already as the complete
+ 		    *  transmission, but not without giving the user
+ 		    *  an alert.  I don't know about all the different
+ 		    *  TCP stacks for VMS etc., so this is currently
+ 		    *  only for UNIX. - kw
+ 		    */
+ 		    HTInetStatus("NETREAD");
+ 		    HTAlert("Unexpected server disconnect.");
+ 		   CTRACE(tfp,
+ 	    "HTCopy: Unexpected server disconnect. Treating as completed.\n");
+ 		   status = 0;
+ 		   break;
+ #else  /* !UNIX */
  		   /*
  		    *  Treat what we've gotten already
  		    *  as the complete transmission. - FM
***************
*** 605,611 ****
--- 640,667 ----
  	    "HTCopy: Unexpected server disconnect. Treating as completed.\n");
  		   status = 0;
  		   break;
+ #endif /* UNIX */
+ 		}
+ #ifdef UNIX
+ 	    } else {		/* status < 0 and other errno */
+ 		/*
+ 		 *  Treat what we've received already as the complete
+ 		 *  transmission, but not without giving the user
+ 		 *  an alert.  I don't know about all the different
+ 		 *  TCP stacks for VMS etc., so this is currently
+ 		 *  only for UNIX. - kw
+ 		 */
+ 		HTInetStatus("NETREAD");
+ 		HTAlert("Unexpected read error.");
+ 		if (bytes) {
+ 		    (void)NETCLOSE(file_number);
+ 		    rv = HT_LOADED;
+ 		} else {
+ 		    (*targetClass._abort)(sink, NULL);
+ 		    rv = -1;
  		}
+ 		goto finished;
+ #endif
  	    }
  	    break;
  	}
***************
*** 641,646 ****
--- 697,714 ----
  **   graphic (or other) objects described by the file.
  **
  **
+ **  State of file and target stream on entry:
+ **  			FILE* (fp) assumed open,
+ **			target (sink) assumed valid.
+ **
+ **  Return values:
+ **	HT_INTERRUPTED  Interruption after some data read.
+ **	HT_PARTIAL_CONTENT	Error after some data read.
+ **	-1		Error before any data read.
+ **	HT_LOADED	Normal end of file indication on reading.
+ **
+ **  State of file and target stream on return:
+ **	always		fp still open, target stream still valid.
  */
  PUBLIC int HTFileCopy ARGS2(
  	FILE *, 		fp,
***************
*** 701,706 ****
--- 769,786 ----
  **   graphic (or other) objects described by the file.
  **
  **
+ **  State of file and target stream on entry:
+ **  		      gzFile (gzfp) assumed open (should have gzipped content),
+ **		      target (sink) assumed valid.
+ **
+ **  Return values:
+ **	HT_INTERRUPTED  Interruption after some data read.
+ **	HT_PARTIAL_CONTENT	Error after some data read.
+ **	-1		Error before any data read.
+ **	HT_LOADED	Normal end of file indication on reading.
+ **
+ **  State of file and target stream on return:
+ **	always		gzfp still open, target stream still valid.
  */
  PRIVATE int HTGzFileCopy ARGS2(
  	gzFile, 		gzfp,
***************
*** 807,812 ****
--- 887,916 ----
  **   CRLF at the end of lines which need to be stripped to LF for unix
  **   when the format is textual.
  **
+ **  State of socket and target stream on entry:
+ **  			socket (file_number) assumed open,
+ **			target (sink) usually NULL (will call stream stack).
+ **
+ **  Return values:
+ **	HT_INTERRUPTED  Interruption or error after some data received.
+ **	-501		Stream stack failed (cannot present or convert).
+ **	-2		Unexpected disconnect before any data received.
+ **	-1		Stream stack failed (cannot present or convert), or
+ **			Interruption or error before any data received, or
+ **			(UNIX) other read error before any data received, or
+ **			download cancelled.
+ **	HT_LOADED	Normal close of socket (end of file indication
+ **			received), or
+ **			unexpected disconnect after some data received, or
+ **			other read error after some data received, or
+ **			(not UNIX) other read error before any data received.
+ **
+ **  State of socket and target stream on return depends on return value:
+ **	HT_INTERRUPTED	socket still open, target aborted.
+ **	-501		socket still open, target stream NULL.
+ **	-2		socket still open, target freed.
+ **	-1		socket still open, target stream aborted or NULL.
+ **	otherwise	socket closed,	target stream freed.
  */
  PUBLIC int HTParseSocket ARGS5(
  	HTFormat,		rep_in,
***************
*** 841,847 ****
      if (rv != -1 && rv != HT_INTERRUPTED)
  	(*targetClass._free)(stream);
  
!     return rv; /* full: HT_LOADED;  partial: HT_INTERRUPTED;  no bytes: -1 */
  }
  
  /*	Parse a file given format and file pointer
--- 945,952 ----
      if (rv != -1 && rv != HT_INTERRUPTED)
  	(*targetClass._free)(stream);
  
!     return rv;
!     /* Originally:  full: HT_LOADED;  partial: HT_INTERRUPTED;  no bytes: -1 */
  }
  
  /*	Parse a file given format and file pointer
***************
*** 853,858 ****
--- 958,976 ----
  **   CRLF at the end of lines which need to be stripped to \n for unix
  **   when the format is textual.
  **
+ **  State of file and target stream on entry:
+ **  			FILE* (fp) assumed open,
+ **			target (sink) usually NULL (will call stream stack).
+ **
+ **  Return values:
+ **	-501		Stream stack failed (cannot present or convert).
+ **	-1		Download cancelled.
+ **	HT_NO_DATA	Error before any data read.
+ **	HT_PARTIAL_CONTENT	Interruption or error after some data read.
+ **	HT_LOADED	Normal end of file indication on reading.
+ **
+ **  State of file and target stream on return:
+ **	always		fp still open; target freed, aborted, or NULL.
  */
  PUBLIC int HTParseFile ARGS5(
  	HTFormat,		rep_in,
***************
*** 921,926 ****
--- 1039,1060 ----
      return(gzres);
  }
  
+ /*	HTParseGzFile
+ **
+ **  State of file and target stream on entry:
+ **  			gzFile (gzfp) assumed open,
+ **			target (sink) usually NULL (will call stream stack).
+ **
+ **  Return values:
+ **	-501		Stream stack failed (cannot present or convert).
+ **	-1		Download cancelled.
+ **	HT_NO_DATA	Error before any data read.
+ **	HT_PARTIAL_CONTENT	Interruption or error after some data read.
+ **	HT_LOADED	Normal end of file indication on reading.
+ **
+ **  State of file and target stream on return:
+ **	always		gzfp closed; target freed, aborted, or NULL.
+ */
  PUBLIC int HTParseGzFile ARGS5(
  	HTFormat,		rep_in,
  	HTFormat,		format_out,
*** lynx2-8-1.orig/WWW/Library/Implementation/HTFormat.h	Thu Aug  6 07:28:22 1998
--- lynx2-8-1/WWW/Library/Implementation/HTFormat.h	Mon Dec  7 21:34:07 1998
***************
*** 371,377 ****
  HTParseFile: Parse a File through a file pointer
  
     This routine is called by protocols modules to load an object. uses HTStreamStack and
!    HTFileCopy .  Returns HT_LOADED if succesful, <0 if not.
     
   */
  extern int HTParseFile PARAMS((
--- 371,378 ----
  HTParseFile: Parse a File through a file pointer
  
     This routine is called by protocols modules to load an object. uses HTStreamStack and
!    HTFileCopy .  Returns HT_LOADED if successful, can also return HT_PARTIAL_CONTENT,
!    HT_NO_DATA, or other <0 for failure.
     
   */
  extern int HTParseFile PARAMS((
***************
*** 390,396 ****
  HTParseGzFile: Parse a gzipped File through a file pointer
  
     This routine is called by protocols modules to load an object. uses HTStreamStack and
!    HTGzFileCopy .  Returns HT_LOADED if succesful, <0 if not.
   */
  extern int HTParseGzFile PARAMS((
          HTFormat        format_in,
--- 391,398 ----
  HTParseGzFile: Parse a gzipped File through a file pointer
  
     This routine is called by protocols modules to load an object. uses HTStreamStack and
!    HTGzFileCopy.  Returns HT_LOADED if successful, can also return HT_PARTIAL_CONTENT,
!    HT_NO_DATA, or other <0 for failure.
   */
  extern int HTParseGzFile PARAMS((
          HTFormat        format_in,
*** lynx2-8-1.orig/WWW/Library/Implementation/HTTCP.c	Sat Oct 24 11:49:07 1998
--- lynx2-8-1/WWW/Library/Implementation/HTTCP.c	Mon Dec  7 21:50:40 1998
***************
*** 17,23 ****
  */
  
  #include <HTUtils.h>
- #include <HTAccess.h>
  #include <HTParse.h>
  #include <HTAlert.h>
  #include <HTTCP.h>
--- 17,22 ----
***************
*** 1095,1101 ****
      fd_set readfds;
      struct timeval timeout;
      int tries=0;
! #ifdef UCX
      int nb;
  #endif /* UCX, BSN */
  
--- 1094,1100 ----
      fd_set readfds;
      struct timeval timeout;
      int tries=0;
! #if defined(UNIX) || defined(UCX)
      int nb;
  #endif /* UCX, BSN */
  
***************
*** 1152,1159 ****
      }
  
  #if !defined(UCX) || !defined(VAXC)
      return SOCKET_READ (fildes, buf, nbyte);
! #else
      /*
      **	VAXC and UCX problem only.
      */
--- 1151,1175 ----
      }
  
  #if !defined(UCX) || !defined(VAXC)
+ #ifdef UNIX
+     while ((nb = SOCKET_READ (fildes, buf, nbyte)) == -1) {
+ 	int saved_errno = errno;
+ 	if (errno == EINTR)
+ 	    continue;
+ #ifdef ERESTARTSYS
+ 	if (errno == ERESTARTSYS)
+ 	    continue;
+ #endif /* ERESTARTSYS */
+ 	HTInetStatus("read");
+ 	errno = saved_errno;	/* our caller may check it */
+ 	break;
+     }
+     return nb;
+ #else  /* UNIX */
      return SOCKET_READ (fildes, buf, nbyte);
! #endif /* !UNIX */
! 
! #else  /* UCX && VAXC */
      /*
      **	VAXC and UCX problem only.
      */
*** lynx2-8-1.orig/WWW/Library/Implementation/HTTelnet.c	Thu Sep 17 05:43:48 1998
--- lynx2-8-1/WWW/Library/Implementation/HTTelnet.c	Mon Dec  7 20:32:26 1998
***************
*** 35,42 ****
  #include <LYStrings.h>
  #include <LYLeaks.h>
  
- #define HT_NO_DATA -9999
- 
  
  /*	Telnet or "rlogin" access
  **	-------------------------
--- 35,40 ----
*** lynx2-8-1.orig/WWW/Library/Implementation/HTUtils.h	Wed Sep 30 16:06:48 1998
--- lynx2-8-1/WWW/Library/Implementation/HTUtils.h	Mon Dec  7 20:37:35 1998
***************
*** 271,279 ****
  #define FALSE   (BOOLEAN)0
  #endif
  #endif   /*  CURSES  */
! #endif   /* _WINDOWS */
  #define BOOLEAN_DEFINED
! #endif
  
  #ifndef BOOL
  #define BOOL BOOLEAN
--- 271,279 ----
  #define FALSE   (BOOLEAN)0
  #endif
  #endif   /*  CURSES  */
! #endif	 /*  BOOLEAN_DEFINED */
  #define BOOLEAN_DEFINED
! #endif   /* _WINDOWS */
  
  #ifndef BOOL
  #define BOOL BOOLEAN
***************
*** 314,320 ****
  #define HT_CANNOT_TRANSLATE -4
  #define HT_NO_ACCESS    -10             /* Access not available */
  #define HT_FORBIDDEN    -11             /* Access forbidden */
! #define HT_INTERNAL     -12             /* Weird -- should never happen. */
  #define HT_BAD_EOF      -12             /* Premature EOF */
  
  
--- 314,322 ----
  #define HT_CANNOT_TRANSLATE -4
  #define HT_NO_ACCESS    -10             /* Access not available */
  #define HT_FORBIDDEN    -11             /* Access forbidden */
! #define HT_NO_DATA		-204	/* OK but no data was loaded - */
! 					/* possibly other app started or forked */
! #define HT_INTERNAL             -900    /* Weird -- should never happen. */
  #define HT_BAD_EOF      -12             /* Premature EOF */
  
  

Message #25 received at 24082@bugs.debian.org (full text, mbox, reply):

From: Brian May <bam@snoopy.apana.org.au>

To: 24082@bugs.debian.org

Subject: Lynx aborts download with no error

Date: Sun, 26 Sep 1999 13:30:13 +1000

Hello,

Has the patch in this bug report been applied to any release of Lynx???

I have the follwoing version of lynx:

Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name            Version        Description
+++-===============-==============-============================================
ii  lynx            2.8.1-3        Text-mode WWW Browser

Yesterday, lynx wouldn't let me download a 9.5Mb file, directly from a
host on the other end of my PPP connection, without constantly aborting.
I ended up using ncftp instead. So far ncftp hasn't aborted once
(although efficiency is poor, another problem I am trying to resolve,
unsucessfully with my PPP link. Transfer rates were higher yesterday
when testing lynx).

The problem occured download a file via HTTP with and without a squid
proxy. The server is "Server: Apache/1.2.5".

I don't mind so much that the tranfer aborts (although it shouldn't).
What *really* annoys me is that lynx pretends that the transfer worked
OK. I save the file, exit lynx, try to uncompress the file, and suddenly
find half of it is missing.

Just today, I downloaded a 619832 byte file. Only 618945 bytes were
received. If I didn't know better, I would have complained to the source
that the file was currupt, as only the last 1kb was missing (it looked
OK to me). Next complete re-download it worked.
-- 
Brian May <bam@snoopy.apana.org.au>

Message #30 received at 24082@bugs.debian.org (full text, mbox, reply):

From: Thomas Hood <jdthood@mail.com>

To: 24082@bugs.debian.org

Cc: bam@snoopy.apana.org.au, chrish@debian.org, kweide@tezcat.com

Subject: 24082 still a problem?

Date: 05 Dec 2001 19:06:24 -0500

Does lynx still download files only partially without
reporting an error, as reported in #24082?

Message #35 received at 24082@bugs.debian.org (full text, mbox, reply):

From: Brian May <bam@snoopy.apana.org.au>

To: Thomas Hood <jdthood@mail.com>

Cc: 24082@bugs.debian.org, chrish@debian.org, kweide@tezcat.com

Subject: Re: 24082 still a problem?

Date: 07 Dec 2001 10:35:30 +1100

>>>>> "Thomas" == Thomas Hood <jdthood@mail.com> writes:

    Thomas> Does lynx still download files only partially without
    Thomas> reporting an error, as reported in #24082?

I am afraid I don't know - it has been a while since I last used lynx
to download large files for this reason.

Next time I need to download I large file, I will use lynx to download
it and see what happens.
-- 
Brian May <bam@snoopy.apana.org.au>

Message #40 received at 24082-done@bugs.debian.org (full text, mbox, reply):

From: James Troup <james@nocrew.org>

To: 24082-done@bugs.debian.org

Subject: Re: lynx: lynx fails to download entire file if file is large(?)

Date: Tue, 06 May 2003 18:26:36 +0100

Brian May <bam@snoopy.apana.org.au> writes:

> >>>>> "Thomas" == Thomas Hood <jdthood@mail.com> writes:
> 
>     Thomas> Does lynx still download files only partially without
>     Thomas> reporting an error, as reported in #24082?
> 
> I am afraid I don't know - it has been a while since I last used lynx
> to download large files for this reason.
> 
> Next time I need to download I large file, I will use lynx to download
> it and see what happens.

That was in Dec 2001.  If this is still a problem, feel free to reopen
the bug.

-- 
James

Send a report that this bug log contains spam.