-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rich Cook wrote: > On OS X, if a filename on the FTP server contains spaces, and the remote > copy of the file is newer than the local, then wget gets thrown into a > loop of "No such file or directory" endlessly. I have changed the > following in ftp-simple.c, and this fixes the error. > Sorry, I don't know how to use the proper patch formatting, but it > should be clear.
I and another developer could not reproduce this problem, either in the current trunk or in wget 1.10.2. > sprintf(filecopy, "\"%.2047s\"", file); This fix breaks the FTP protocol, making wget instantly stop working with many conforming servers, but apparently start working with yours; the RFCs are very clear that the file name argument starts right after the string "RETR "; the very next character is part of the file name, including if the next character is a space (or a quote). The file name is terminated by the CR LF sequence (which implies that the sequence CR LF may not occcur in the filename). Therefore, if you ask for a file "file.txt", a conforming server will attempt to find and deliver a file whose name begins and ends with double-quotes. Therefore, this seems like a server problem. Could you please provide the following: 1. The version of wget you are running (wget --version) 2. The exact command line you are using to invoke wget 3. The output of that same command line, run with --debug Thank you very much. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl9KT7M8hyUobTrERCJfoAJ91z9c2GniuoaX0mj9oqzHrrpNCtQCePQnm lvbVe0i5/jVy9V10uQpYgmk= =iQq1 -----END PGP SIGNATURE-----
