(*** This bug was imported into bugs.kde.org ***) Package: konqueror Version: 3.0.1 (using KDE 3.0.1 ) Severity: normal Installed from: SuSE Compiler: gcc version 2.95.3 20010315 (SuSE) OS: Linux (i686) release 2.4.18 OS/Compiler notes: According to the FTP RFC the output of the LIST command may be in EBCDIC. There aren't many sites out there running such a server [1] but a friend of mine's got DJB's publicfile [2] running [3] which is one case. With Konqueror neither can I access the listing nor can I download a file from his server. (This might change as he's currently hacking publicfile's ftpd to return ASCII output.) Greets Malte [1]http://www.google.de/search?q=cache:jxi1pdM366QC:listserver.uk.freebsd.org/pipermail/freebsd-users/2002-February/005296.html+weird+ftp+publicfile+output&hl=de&lr=lang_de|lang_en&ie=UTF-8 [2]http://cr.yp.to/publicfile/ [3]ftp://ftp.soohrt.org (Submitted via bugs.kde.org) (Called from KBugReport dialog)
ftp://ftp.soohrt.org has indeed been changed to output a standard FTP listing output. I can't fix this bug then... Any other site that still works in EBCDIC? The given urls in the report seem to have changed too. [1] is a completely unrelated message (although it has ebcdic in it) [2] says 'file does not exist' Please reopen if you know another EBCDIC ftp site.
Try [4]. [2] should have been [5]. Oh, and here's [6] the hack against publicfile to make it generate ASCII output, if anybody's interested. [4]ftp://cr.yp.to [5]http://cr.yp.to/publicfile.html [6]http://source.soohrt.org/patches/publicfile.patch
Actually, I think the problem is that the output to the LIST command is in EPLF format instead of the normal ls -l style. I'd have to check the RFCs, but I don't believe they mandate a format for the output of a LIST command. Maybe at the time there was no software parsing... (RFC 959) Mozilla can parse the output fine.
Changing to wishlist.
After all that JJ talk on core-devel I just wanted to drop a note that thanks to coolo's mail I went and coded this feature yesterday night :) I need to get rid of some rough edges (and grok some of kio_ftp's oddities), then I'll attach the patch to this bug.
*** Bug 102811 has been marked as a duplicate of this bug. ***
Malte: what is the status on your EPLF patch? Has it been committed? This bug report is still open. If you don't have the time to sort the rough edges, attach the patch and we'll work on it.
Doh, I completely forgot bout this bug. I have to look through my harddisk to find the patch again. The reason why I didn't attach it yet was that I failed to set up a test server with publicfile (at least without having djb all over my system). Will have a look for the patch the next few days.
*** Bug 98136 has been marked as a duplicate of this bug. ***
Malte: any news? I'm upgrading this to "bug", since it's the only way we can support FTP servers that don't list directories in the Unix /bin/ls format.
Hmmm... I was sure that I attached the patch, (actually, two patches) to this bug. Seems like this bug doesn't like me :) Weird. Thiago, David, did I maybe send it to some of you directly? Because I doubt that I still have it on my harddisk. From my memories, one of the two patches was a rather hackish attempt to hook in the EPLF parsing running, the other one was almost a rewrite of the existing code using QRegExp instead of (deprecated) strtok. It also included a parsing routine for DOS listings. I remember that I asked why that code didn't use QRegExp in the first place if there's some rule against using such a "high level" class in kio.
I could try scanning my old mailboxes for this, but it won't be easy. I'll let you know if I find it (but I doubt I will).
Its probably easier rewriting the code, it wasnt that much. To clear this up: Is there any reason against using QRegExp in KIO?
*** Bug 126219 has been marked as a duplicate of this bug. ***