Bug 189979 - pwd displays '%2F' as a part of path
Summary: pwd displays '%2F' as a part of path
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lftp (Show other bugs)
(Show other bugs)
Version: 4.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Jason Vas Dias
QA Contact:
Depends On:
Blocks: 189980 189986
TreeView+ depends on / blocked
Reported: 2006-04-26 13:22 UTC by David Kovalsky
Modified: 2014-03-31 23:43 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-29 00:06:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Kovalsky 2006-04-26 13:22:49 UTC
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):

How reproducible:

Steps to Reproduce:
1. `lftp -u root localhost` (the same results for ordinary user)
Password: (type your password)
lftp root@localhost:~>

2. `pwd`

3. `cd`  (or `ls` or whatever)
cd ok, cwd=/root

4. `pwd`

Actual results:

Expected results:

Additional info:
FTP server was vsftpd version 2.0.1

Comment 1 Jason Vas Dias 2006-04-29 00:06:41 UTC
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

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

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
lftp user@host:~> cd ~
lftp user@host:~> pwd
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,

Note You need to log in before you can comment on or make changes to this bug.