bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] New option "--no-list-a"


From: Tim Rühsen
Subject: Re: [Bug-wget] New option "--no-list-a"
Date: Sat, 31 Aug 2013 19:57:47 +0200
User-agent: KMail/4.10.5 (Linux/3.10-2-amd64; KDE/4.10.5; x86_64; ; )

I like Stevens 'SYST' approach.

The proposed steps for a patch will be

- issue a SYST command and check 215 output
- if the kind of server is known by Wget, we also know if we use
  LIST or "LIST -a". We also know the output format.
- if we don't know the server, fallback to
        - add a comment why LIST -a is tried before LIST
        - if LIST -a returns an empty listing, Wget should fallback to LIST

And Steven is right, unknown servers might return the directory listing in an 
unknown format. RFC 959 leaves the output format completly open.

I saw so far
215 UNIX Type: L8 -> LIST -a, Unix output format

215 Windows_NT -> LIST, MSDOS/Windows output format

215 UNIX MultiNet Unix Emulation V5.3(93) -> LIST, Unix output format

Regards, Tim

Am Samstag, 31. August 2013, 10:24:10 schrieb Steven M. Schweda:
> > some systems (at least info-zip.org) have problems with the ftp
> > command "LIST -a".
> 
>    If you use an interactive FTP client with that system, you might
> notice some interesting things about that FTP server.  For example:
> 
        > 220 server.tmk.com MultiNet FTP Server Process V5.3(17) at [...]
> 
> That is, it's part of a third-party (Process Software) IP software
> package for a VMS system.  Also:
> 
> 230- The default listing format is Unix-style. For VMS-style, say "cd []".
> 
> There's some code in Wget to deal with the way this particular FTP
> server can switch listing formats (between UNIX-ls-like and
> VMS-DIRECTORY), too.
> 
>    In my (limited) experience, generally, "LIST -a", though
> non-standard, is interpreted as desired by FTP servers on UNIX(-like)
> systems, but it can be expected to cause problems with other FTP
> servers, including some which try to emulate a UNIX(-like) FTP server.
> Which is why there's VMS-specific code to avoid it for FTP servers
> which identify themselves as "VMS".  Apparently, this MultiNet FTP
> server is configured to provide a file listing in a UNIX-like format (at
> least initially), but that does not mean that it emulates all features
> of a typical UNIX(-like) FTP server.
> 
>    I'd guess that the (vast?) majority of FTP servers which look like
> UNIX(-like) FTP servers would deal with "LIST -a" as expected, but some
> will not.  I was content to deal with the problem on obviously VMS FTP
> servers, but this MultiNet FTP server is one which can try to look
> UNIX-like, but which does not do "LIST -a" as expected.  I doubt that a
> good, general solution exists.  Asking the user to specify "--no-list-a"
> seems far from ideal.
> 
> > - if LIST -a returns an empty listing, Wget should fallback to LIST
> 
> Looking for an empty listing from "LIST -a" will work in some (most?)
> cases, and it's simple, but what happens if there's a file named "-a" on
> the server?  It might actually be smarter to look at SYST output, and
> maintain a list of UNIX(-like) servers where "LIST -a" is known to fail.
> It might be ugly, but it might also be more reliable than other ways.
> For the first one on the list, I'd nominate this one:
> 
> FTP> quote "SYST"
> 215 UNIX MultiNet Unix Emulation V5.3(93)
> 
> Recognizing "MultiNet" should be good enough.
> 
>    Of course, the fundamental problem here is the way "ls" on a
> UNIX(-like) system (and, hence, a typical FTP LIST) can't be trusted to
> provide a complete directory listing.  But there's no chance of getting
> all those FTP servers fixed, either.
> 
> ------------------------------------------------------------------------
> 
>    Steven M. Schweda               address@hidden
>    382 South Warwick Street        (+1) 651-699-9818
>    Saint Paul  MN  55105-2547

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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