bug-wget
[Top][All Lists]
Advanced

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

[Bug-wget] [ PATCH ] LIST changes (ver. 3)


From: Andrea Urbani
Subject: [Bug-wget] [ PATCH ] LIST changes (ver. 3)
Date: Fri, 18 Oct 2013 03:46:34 -0400

Hello Tim,

attached the version 3 of the LIST changes created as you asked me.
Version 3 because I received the following answer about MultiNet:

----
It looks like the server side (Multinet) is starting in UNIX mode. This is done 
using a logical:

MULTINET_FTP_UNIX_STYLE_BY_DEFAULT

when this logical is defined then the FTP Server starts in UNIX emulation mode.

If the FTP Server is in UNIX mode, the SYST command displays the banner "UNIX 
MultiNet Unix Emulation." If the FTP Server is in VMS mode, the SYST command 
displays the equivalence string associated with theMULTINET_FTP_SYST_BANNER 
logical name (if defined). Otherwise, the SYST command displays "VMS MultiNet 
Vx.y(rev)":


With regards to "ls -a" or "list -a", in VMS which where Multinet is running 
there are no hidden files. So, an LS does the trick. There is no need for VMS 
to implement a switch for
hidden files since there aren't any.
----

So, about the "VMS MultiNet" no problems because "VMS" is found and so LIST is 
forced.
About "UNIX MultiNet" I changed the source to look only for

215 UNIX MultiNet Unix Emulation
instead of
215 UNIX MultiNet Unix Emulation V5.3(93)
About MULTINET_FTP_SYST_BANNER, well, if the user choose to write "UNIX Type: 
L8" wget will force "LIST -a" and you will get no files from that server...
So, or we think positive that nobody will do it or we have to remove the 
possibility to force "LIST -a"; that means wget will only force "LIST" on known 
system and, in all the other cases, it tries, only the first time, "LIST -a", 
"LIST" and decides which one to use for the session. More compatible, but more 
heavy (more traffic).
Let's think about it...
It is just a comment work of 6 lines inside ftp.c to not force "LIST -a" at all.
 else if ( con->rsu == UST_TYPE_L8 )
 {
 DEBUGP (("\nUNIX TYPE L8: I know it and I will use \"LIST -a\" as standard 
list command\n"));
 con->st |= LIST_AFTER_LIST_A_CHECK_DONE;
 con->st |= AVOID_LIST;
 }
Bye
Andrea
----- Original Message -----
From: Tim Rühsen
Sent: 10/17/13 09:04 PM
To: address@hidden
Subject: Re: [ PATCH ] LIST changes (ver. 2)

Am Donnerstag, 17. Oktober 2013, 12:55:18 schrieb Andrea Urbani: > Hi, > first 
of all I'm sorry: I was not subscribed to the bug-wget list so I saw > only 
yesterday the replies of other users. > > Well, this patch replaces the 
previous ones from me. > > Now wget, after the SYST command, looks if it knows 
that system. > If yes, wget will force the use of "LIST" or "LIST -a". > If no, 
wget will try, only the first time of each session, before the > "LIST -a" 
command and after the "LIST". > If "LIST -a" works and returns more or equal 
data of the "LIST", > "LIST -a" will be the standard list command for all the 
session. > If "LIST -a" fails or returns less data than "LIST" (think on the 
case > of an existing file called "-a"), "LIST" will be the standard list > 
command for all the session. > > Well, there is an unhandled situation (that I 
will not fix, at least > now): I'm on an unknown system that recognise "LIST 
-a" as "give me the > -a files/folders", I have to download files from 
different folders and > the starting ftp folder contains.... only one "-a" 
folder and no "." and > ".." folders are returned ! :-O) > In this case wget 
will try "LIST -a" then "LIST". The result will be > the same so "LIST -a" will 
be taken, but, as soon as wget will go > inside the "-a" folder, the problems 
will begin... > > About the look for known systems I force LIST when the system 
is ST_VMS or > exactly "215 UNIX MultiNet Unix Emulation V5.3(93)". If the 
system is like > "215 UNIX Type: L8" I force "LIST -a". > In all the other 
systems, I try "LIST -a" and after "LIST" (only the first > time). I don't 
force "LIST" for ST_WINNT because in ftp-ls.c is written, > inside 
ftp_parse_ls, > > /* Detect whether the listing is simulating the UNIX format 
*/ > > so there are strange situations there, that I can't test. > > About 
MultiNet I have written to the developers to know if I can check a > more 
general "215 UNIX MultiNet " or not. > > I have tested the sites: > 
ftp://ftp.info-zip.org/ > ftp://ftp.freebsd.org/ > 
ftp://antinode.info/moz_test/ > ftp://ftp.microsoft.com/ > ftp://ftp.adobe.com/ 
> ftp://ftp.gnu.org/ > ftp://ftp.ncftp.com/ > > I have also added the following 
test cases: > > * Test-ftp-list-Multinet.px: Test LIST on a "UNIX MultiNet > 
Unix Emulation" system that returns an empty content when > "LIST -a" is 
requested (probably because no "-a" files > exist) > > * 
Test-ftp-list-Unknown.px: Test LIST on a "Unknown ftp > service" system that 
returns an empty content when > "LIST -a" is requested (probably because no 
"-a" files > exist) > > * Test-ftp-list-Unknown-a.px: Test LIST on a "Unknown 
ftp > service" system that recognises "LIST -a" as "give me the > -a file" and 
there is a "-a" file + other two files. > "LIST -a" will return only "-a", 
"LIST" all the three files. > > * Test-ftp-list-Unknown-hidden.px: Test LIST on 
a "Unknown ftp > service" system that recognises "LIST -a" as an "UNIX Type: > 
L8" system (show me also the hidden files) and there is an > hidden file. > > * 
Test-ftp-list-Unknown-list-a-fails.px: Test LIST on a > "Unknown ftp service" 
system that raises an error on > "LIST -a" command. > > * 
Test-ftp-list-UNIX-hidden.px: Test LIST on a "UNIX Type: > L8" system that 
recognises "LIST -a" as "show me also the > hidden files" and there is an 
hidden file. > > Everything should be ok. If not, let me know. (Now I'm 
subscribed to > bug-wget) Hey Andrea, nice work. But I just can't apply your 
patch to up-to-date Wget sources (patch throws messages at me and thereafter 
Wget is not compilable at all). Maybe you can commit all your changes locally 
and create a patch with git format-patch -1 ? Regards, Tim

Attachment: list_ver3.zip
Description: Attachment: list_ver3.zip


reply via email to

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