From: Matthew Atkinson > Would it be reliable enough to try CWD to it [...]
I believe that that's the standard method. For example, googlebot seems to do similar things all the time (for plain-old files, not even for symlinks): [...] 5:34.00 User:anonymous logged in ident:[email protected] from Host:66.249.69.179 5:34.40 User:anonymous ident:[email protected] status:07649912 CWD dir:robots.txt 5:34.68 User:anonymous ident:[email protected] status:00000000 RETR file:SYS$SYSDEVICE:[ANONYMOUS]robots.txt;1 [...] > [...] what is the safest way to restore the original PWD? [...] I haven't tested it anywhere, so I know nothing, but I'd guess that if you ask the server where it is -- ftp_pwd() -- and then feed that result back into ftp_cwd(), then any server should be happy. (That's essentially what the mess in getftp() is doing to deal with a relative path.) [...] And what should be done on error in this case? Exploit "Roe v. Wade"? Suicide? > The only call to ftp_cwd() is wrapped in code which seems to be there to > deal with VMS. The mess for dealing with a VMS server is forced by the way Wget (specifically, getftp()) sends a UNIX-like path spec instead of following the RFC (that is, sending the path segments individually). If you ask the server using ftp_pwd(), and then return what it said using ftp_cwd(), then no special handling should be needed for any competent server (or even for a VMS server). > Does this need to be done in this case, No. (I believe.) > and if so should > this be moved into ftp_cwd() or another function so it can be reused? No. ftp_cwd() is a simple, primitive function which should do what it does, namely send a CWD command. The mess in getftp() is specific to the way getftp() works; it's not there because of a flaw in ftp_cwd(). ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547
