Know bug number 6 states:
libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that such parts should be sent to the server as 'CWD ' (without an argument). The only exception to this rule, is that we knowingly break this if the empty part is first in the path, as then we use the double slashes to indicate that the user wants to reach the root dir (this exception SHALL remain even when this bug is fixed).
I think this means libcurl will ignore double slashes unless it's the first in the path, which will bring us to the root dir. But that's not what is happening. libcurl is always ignoring the double slashes leaving us with no way to list the root directory. (Except .. hacks)
Logged In: YES
user_id=1110
Originator: NO
I can't repeat (or possibly understand) your problem:
I take it you use 7.16.2 or a recent CVS?
I tried with both doing this:
$ curl ftp://ftp.sunet.se//lib/ -v
And both versions jump to the directory "/lib" that is based on the root dir of the server, not the home dir where it logs in.
I also tried the more official way of doing it, by specifying %2f instead of the double slash, it it too worked with both these versions:
$ curl ftp://ftp.sunet.se/%2flib/ -v
Logged In: YES
user_id=307089
Originator: YES
This indeed works. But if you try just ftp://ftp.sunet.se// you won't be changed to the root dir. ftp.sunet.se doesn't have a default home dir, but you can see that there is no CWD / command given. Using ftp://ftp.sunet.se/%2F works well.
I tried with curl-7.16.2.
Logged In: YES
user_id=1110
Originator: NO
Sorry, but can you tell me what the problem is with this. ftp://ftp.sunet.se// gets the root dir for you.
> Using ftp://ftp.sunet.se/%2F works well.
Actually, that does NOT work well I would say as that will make curl issue "RETR /" which is plain wrong.
But ok, please confirm the following: I guess the problem here is you want to list the root dir of an FTP server that doesn't let you in in the root dir as default and you say this doesn't work? If it is, do you know of a public server that you can repeat the problem with with a complete command line?
(I guess you've said this all along but I haven't understood it)
Logged In: YES
user_id=307089
Originator: YES
ftp://ftp.sunet.se// gets the root dir because ftp.sunet.se doesn't redirect you to a default dir. You can try it with curl -v and see that there is no CWD / command being issued. I can reproduce it locally with a FTP server that I configured:
$ curl -v ftp://robson@localhost//
* About to connect() to localhost port 21 (#0)
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 21 (#0)
< 220 ProFTPD 1.3.1rc2 Server (ProFTPD Default Installation) [127.0.0.1]
> USER robson
< 331 Anonymous login ok, send your complete email address as your password
> PASS
< 230 Anonymous access granted, restrictions apply
> PWD
< 257 "/ssh" is the current directory
* Entry path is '/ssh'
> EPSV
* Connect data stream passively
< 229 Entering Extended Passive Mode (|||46110|)
* Trying 127.0.0.1... connected
* Connecting to 127.0.0.1 (127.0.0.1) port 46110
> TYPE A
< 200 Type set to A
> LIST
< 150 Opening ASCII mode data connection for file list
* Maxdownload = -1
* Remembering we are in dir /
< 226 Transfer complete
* Connection #0 to host localhost left intact
* Curl_disconnect
> QUIT
< 221 Goodbye.
* Closing connection #0
It is listing /ssh directory instead of the / directory.
Logged In: YES
user_id=1110
Originator: NO
I get it now. Funnily enough, the bug does not appear when using --ftp-method singlecwd
Logged In: YES
user_id=1110
Originator: NO
I've committed fix for this now, and two test cases.
Logged In: YES
user_id=307089
Originator: YES
Thanks for fixing.
> Funnily enough, the bug does not appear when using
> --ftp-method singlecwd
This is a bug too. If you use --ftp-method singlecwd, libcurl always sets the path to /, despite an extra slash or not, instead of leaving you in the default dir.
Logged In: YES
user_id=307089
Originator: YES
Also, if you use CURLFTPMETHOD_NOCWD, libcurl always does a SIZE and a RETR, even if the url points to a directory.
Patch for making CURLFTPMETHOD_NOCWD work with directories
Logged In: YES
user_id=307089
Originator: YES
Here is a patch for the nocwd problem. I haven't looked into the singlecwd issue.
File Added: nocwd.patch
Logged In: YES
user_id=1110
Originator: NO
The nocwd.patch makes it do a directory listing, sure but it breaks the promise of "no cwd". As test case 351 easily proves... Therefore I don't consider it to be the proper fix. BTW, this nocwd bug is now added to the KNOWN_BUGS document and I consider it separate from the problems we attempt to fix in this bug report. It simply is broken.
I don't see any problem with singlecwd, neither with listing to the root dir (test case 352) or listing a custom dir relative from the logged in dir (test case 297).
Logged In: YES
user_id=307089
Originator: YES
Ok. Let's break this into two issues:
singlecwd:
*Always* does a CWD /. This breaks the case where the server wants to put you in a /home/user dir by default.
nocwd:
Current - doesn't work for directories, nocwd for files.
Proposed - one cwd for directories, nocwd for files.
Logged In: YES
user_id=1110
Originator: NO
singlecwd:
Just now I tried this with current CVS:
curl ftp://ftp.sunet.se// --ftp-method singlecwd -v
and
curl ftp://ftp.sunet.se/pub/ --ftp-method singlecwd -v
The first did a CWD / and a LIST, while the second did a "CWD pub" and a LIST. I can't see a problem?
nocwd:
for directories we should probably make the directory name get used in the LIST command instead, so that no CWD is used and LIST specifies the full path. But I honestly don't plan on fixing this before the upcoming release, while I want the problem you filed originally (with at least the default ftp method setting) to work fine.
Logged In: YES
user_id=307089
Originator: YES
singlecwd:
Try
curl ftp://ftp.sunet.se/ --ftp-method singlecwd -v
It will do a CWD / when it shouldn't. That's the issue.
nocwd:
I agree.
Logged In: YES
user_id=1110
Originator: NO
Ah, ok, but that's expected since libcurl has no such path optimizing logic. We could make one, but currently it will do this extra step.
Logged In: YES
user_id=307089
Originator: YES
No, Daniel. libcurl can't issue a CWD / because it breaks the case where the server puts you in a /home/user directory by default.
Logged In: YES
user_id=1110
Originator: NO
ugh, of course. me stupid...
Logged In: YES
user_id=1110
Originator: NO
I added test case 353 now that tests this and I committed a fix that makes the test run fine in my end!
Logged In: YES
user_id=307089
Originator: YES
I verified that it works for me. Thanks, Daniel.
Logged In: YES
user_id=1110
Originator: NO
Phew. Thanks for your report and patience with me. Closing this now.