Bug 189979 - pwd displays '%2F' as a part of path
pwd displays '%2F' as a part of path
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lftp (Show other bugs)
4.0
All Linux
low Severity low
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks: 189980 189986
  Show dependency treegraph
 
Reported: 2006-04-26 09:22 EDT by David Kovalsky
Modified: 2014-03-31 19:43 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-28 20:06:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Kovalsky 2006-04-26 09:22:49 EDT
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
Comment 1 Jason Vas Dias 2006-04-28 20:06:41 EDT
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.

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