lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev partial not working on ftp:// url's (?)


From: Klaus Weide
Subject: Re: lynx-dev partial not working on ftp:// url's (?)
Date: Tue, 20 Jul 1999 04:52:39 -0500 (CDT)

On Tue, 20 Jul 1999, Kim DeVaughn wrote:

> | > Also, FWIW, if the dir list xfer is interrupted with either the "z"
> | > key, or a ^G, the part of the listing already received does not get
> | > displayed until a ^G (or a 2nd ^G) is issued.
> |
> On Tue, Jul 20, 1999, Leonid Pauzner (address@hidden) said:
> 
> | Hmm, seems you see xfer counter on statusline but no partial output - very
> | strange.

That 'xfer counter' is not the usual HTReadProgress, HTFTP.c is doing it
by hand - look for TRANSFERRED_X_BYTES.

> Yup.
> 
> And it is the only (or 2nd) ^G that causes "Data transfer interrupted."
> to be displayed (along with the 1st screenfull of the dir list received
> thusfar).  Without that ^G, lynx will just sit there, showing a blank
> screen, and the (now static) "Transferred NNNNN bytes" message.

What if that 2nd key is something else than ^G - like 'z' or '^L' or
down arrow?

(I never use ^G for anything except cancelling a prompt or line
editing - it seems weird to me to use it where 'z' should be used.)

What does the lynx process do while it just 'sits there', is it using
CPU time (some loop), does it still have network sockets open?
In any case, a TRACE should give a better idea where things are stuck.

Is this only with -partial enabled?

If not, it may have something to do with the following (end of read_directory
in HTFTP.c):

    if (server_type == APPLESHARE_SERVER ||
        server_type == NETPRESENZ_SERVER) {
        /*
         *  Without closing the data socket first,
         *  the response(NIL) below hangs. - KW
         */
        NETCLOSE(data_soc);
    }

    if (WasInterrupted || HTCheckForInterrupt()) {
        if (server_type != CMS_SERVER)
            response(NIL);
        _HTProgress(TRANSFER_INTERRUPTED);
        return HT_LOADED;
    }
    if (server_type != CMS_SERVER)
        response(NIL);
    return HT_LOADED;

Maybe 'the response(NIL) below hangs' is true not only for those
server types, but also for others.  I added that NETCLOSE a long
time ago, when testing with those weird servers seemed to show
that they needed it, but didn't add it for cases I didn't know
about.  It should probably also be done if WasInterrupted is true
at that point (please test, I don't want to start loading
multimegabyte directory listings now..).


  Klaus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]