Bug 171884
| Summary: | First ls always return an empty list | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nicolas Mailhot <nicolas.mailhot> |
| Component: | lftp | Assignee: | Jason Vas Dias <jvdias> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | michal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-11-23 21:46:46 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 150221 | ||
|
Description
Nicolas Mailhot
2005-10-27 13:42:27 UTC
> (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. 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 Generally speaking, the latest rawhide x86_64 lftp binary is proving buggy as hell and underwhelming 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.
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 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 As stated in Comment #4, lftp-3.3.3-1 has been in Rawhide (and now FC-5test1) since 2005-11-11 . Ok, closing then |