Description of problem: After logging in, change directory or ls and then do a 'pwd'. You will see '%2F' as a part of the path. Version-Release number of selected component (if applicable): lftp-3.0.6-3.i386 How reproducible: always Steps to Reproduce: 1. `lftp -u root localhost` (the same results for ordinary user) Password: (type your password) lftp root@localhost:~> 2. `pwd` ftp://root@localhost 3. `cd` (or `ls` or whatever) cd ok, cwd=/root 4. `pwd` ftp://root@localhost/%2Froot Actual results: ftp://root@localhost/%2Froot Expected results: ftp://root@localhost/root Additional info: FTP server was vsftpd version 2.0.1
Actually, it turns out this is NOTABUG : Surprisingly, FTP clients are REQUIRED to encode a leading '/' the filename part of a CWD url as %2F, by RFC 1738, "Uniform Resource Locators (URL)", Section 3.2.2., "FTP url-path", Page 7: < Within a name or CWD component, the characters "/" and ";" are reserved and must be encoded. The components are decoded prior to their use in the FTP protocol. In particular, if the appropriate FTP sequence to access a particular file requires supplying a string containing a "/" as an argument to a CWD or RETR command, it is necessary to encode each "/". For example, the URL <URL:ftp://myname@host.dom/%2Fetc/motd> is interpreted by FTP-ing to "host.dom", logging in as "myname" (prompting for a password if it is asked for), and then executing "CWD /etc" and then "RETR motd". This has a different meaning from <URL:ftp://myname@host.dom/etc/motd> which would "CWD etc" and then "RETR motd"; the initial "CWD" might be executed relative to the default directory for "myname". On the other hand, <URL:ftp://myname@host.dom//etc/motd>, would "CWD " with a null argument, then "CWD etc", and then "RETR motd". > So the command: $ lftp ftp://user@host lftp user@host:~> implicitly puts you in '~', which is /home/user . (note there is no leading '/') - it is the users default home directory. So when you do: $ lftp ftp://user@host lftp user@host:~> pwd ftp:://user@host because you're in user's default home directory, '~'. but if you do $ lftp ftp://user@host lftp user@host:~> cd cd ok, cwd=/home/user lftp user@host:~> pwd ftp://user@host/%2Fhome/user Here, we did PWD, which returns '/home/user', and then did a CWD to /home/user. CWD now begins with '/', and the URL is : 'ftp://user@host/%2Fhome/user', by RFC 1738 rules, because it is obtained by FTP-ing to the 'ftp://user@host', and CD-ing to /home/user . But if you do: $ lftp ftp://user@host lftp user@host:~> cd cd ok, cwd=/home/user lftp user@host:~> pwd ftp://user@host/%2Fhome/user lftp user@host:~> cd ~ lftp user@host:~> pwd ftp://jvdias@jvdspc lftp user@host:~> We actually sent '~' to the server, which does not begin with a '/', and does not need to be preceded by a %2F . Yes, this highly non-intuitive, but does make weird kind of sense, is compliant with the RFC, and is the way LFTP has always worked - hence, NOTABUG.