Bug 171884 - First ls always return an empty list
First ls always return an empty list
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lftp (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2005-10-27 09:42 EDT by Nicolas Mailhot
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-23 16:46:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2005-10-27 09:42:27 EDT
Description of problem:

When I do an ls in lftp the first ls always return immediatly with an empty
listing. I have to repeat the command to get a result

Version-Release number of selected component (if applicable):

lftp-3.3.2-1

How reproducible:

Always
(but maybe it's my ISP playing tricks with their transparent proxy)
Comment 1 Michal Jaegermann 2005-10-29 15:24:24 EDT
> (but maybe it's my ISP playing tricks with their transparent proxy)
I doubt it.  I have never seen that before but now I noticed that same thing.
Also hitting the same sites with a web browser shows directories all right.

But it looks like that it is a protocol dependent, i.e. I am seeing that when
using http but not ftp, and it also seem to depend on a site; although when
it happens it does the same thing with repeated connections.  Watch:

$ lftp http://download.fedora.redhat.com/pub/fedora/linux/
cd ok, cwd=/pub/fedora/linux
lftp download.fedora.redhat.com:/pub/fedora/linux> dir
lftp download.fedora.redhat.com:/pub/fedora/linux> dir
drwxr-xr-x  --  /
drwxr-xr-x  --  ..
drwxr-xr-x            -  2005-06-09 12:40  core
drwxr-xr-x            -  2005-07-29 13:05  extras

OTOH when trying ftp maybe I was "lucky" and did not run into connections
on which this happens?  I did not attempt a very systematic survey of protocols
and servers but http URL on which I am always getting directory on the first
try is, for example, http://mirrors.cat.pdx.edu/.  An idea that an observed
behaviour may depend on a directory level looks like dismissed by an
http://download.fedora.redhat.com/ counterexample where I have again call
'dir' twice.
Comment 2 Nicolas Mailhot 2005-10-29 16:52:04 EDT
I almost never do ftp nowadays, and I obviously use
http://download.fedora.redhat.com/ often, but I think I saw the same thing on
livna for example.

Anyway, nice to have a second confirmation - I only suspected my ISP because the
bug is so big I'm surprised I was the first to report it
Comment 3 Nicolas Mailhot 2005-11-11 11:16:26 EST
Generally speaking, the latest rawhide x86_64 lftp binary is proving buggy as
hell and underwhelming
Comment 4 Jason Vas Dias 2005-11-11 12:29:23 EST
Sorry about this. We just integrate the latest lftp release (which seems to
change every couple of weeks) into the Fedora build unchanged, and do some
basic tests, which did not expose this problem. The last two lftp releases 
(3.3.1, 3.3.2) were the only ones for over a year to cause any problems. 
I've now built the new lftp-3.3.3-1 release into FC-5/Rawhide, which is also
available from:
    http://people.redhat.com/~jvdias/lftp/
Please try out this version and let me know of any issues - thanks.
 
Comment 5 Nicolas Mailhot 2005-11-11 13:05:05 EST
lftp-3.3.3-1.x86_64.rpm does not seem to exhibit this problem
The test was rather easy - http://people.redhat.com/~jvdias/lftp/ exhibited this bug

Will let you know if I find a problem using this version
Comment 6 Nicolas Mailhot 2005-11-23 15:34:39 EST
After ten days of testing I have nothing bad to say about
lftp-3.3.3-1.x86_64.rpm - you should should it to rawhide
Comment 7 Jason Vas Dias 2005-11-23 16:31:08 EST
As stated in Comment #4, lftp-3.3.3-1 has been in Rawhide (and now FC-5test1)
since 2005-11-11 .
Comment 8 Nicolas Mailhot 2005-11-23 16:46:46 EST
Ok, closing then

Note You need to log in before you can comment on or make changes to this bug.