Subject: SFTP: clarification

From: Simon Tatham <[email-masked]>
Date: Sat, 24 Feb 2001 12:08:51 +0000

Hi,

ssh.com's and OpenSSH's SFTP servers seem to have a difference of
opinion over the semantics of FXP_REALPATH. I read the spec
carefully but couldn't see anything that explicitly stated who was
right.

ssh.com is willing to return a canonical pathname for a nonexistent
file. It returns the string that _would_ be the file's canonical
name if it were to be created. Hence, I can call FXP_REALPATH just
before creating a remote file, and get back the canonical pathname
of the file I'm about to create.

OpenSSH, by contrast, will only return a canonical pathname for a
file that actually exists.

Which of these is the right behaviour, or are they both right? Could
the SFTP draft be clarified on this point please?

Cheers,
Simon
-- 
Simon Tatham         "My heart bleeds.
<[email-masked]>    (That's how it works.)"   -- Gareth Taylor

---

From: [email-masked] (Niels M�ller)
Date: 25 Feb 2001 23:25:16 +0100

> the SFTP draft be clarified on this point please?

I would also like to see some motivation for the FXP_REALPATH feature.
Why does anybody need that?

/Niels

---

From: Damien Miller <[email-masked]>
Date: Mon, 26 Feb 2001 14:53:31 +1100 (EST)

> Why does anybody need that?

It makes it a fair bit easier to write a client, especially since the
server lacks the concept of a current working directory.

-d

-- 
| Damien Miller <[email-masked]> \ ``E-mail attachments are the poor man's 
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer

---

From: Simon Tatham <[email-masked]>
Date: Mon, 26 Feb 2001 09:44:20 +0000

> Why does anybody need that?

It allows you to implement a current working directory in the form
Unix users expect it. That is, typing `pwd' always gives you the
same result if you're in the same directory.

Without FXP_REALPATH, there would be a visual distinction between my
home directory as specified by `.', and my home directory as
specified by `cd /home/simon'. Typing `cd ..' from each would leave
you in `..' and `/home' respectively. A naive user who's used to
`..' being pwd-relative isn't going to be soothed by the idea that
there simply isn't a pwd in the SFTP wire protocol; they will expect
the client to synthesise a plausible pwd _for_ them.

Moreover, there's a subtle change in behaviour given the existence
of symlinks to directories. Consider /usr/doc -> /usr/share/doc, for
example. Without FXP_REALPATH, I type `cd /usr/doc' and then `cd ..'
and end up in /usr; but I type `cd /usr/share/doc' and then `cd ..'
and end up in /usr/share. With FXP_REALPATH, I end up in the _same_
place no matter which I do - which is the behaviour traditional Unix
provides.

(Aside: bash well-meaningly tries to obscure this behaviour, by
keeping its own notion of your pwd which doesn't dereference
symlinks, so `cd /usr/doc' followed by `cd ..' leaves you in /usr;
but this illusion is imperfect and therefore arguably more confusing
than its absence, because it's not shared by anything other than the
shell: so once you've done `cd /usr/doc', `ls ..' will list
/usr/share even though `cd ..' lands you in /usr!)

Cheers,
Simon
-- 
Simon Tatham         "What a caterpillar calls the end of the
<[email-masked]>    world, a human calls a butterfly."

---

From: [email-masked] (Niels Möller)
Date: 26 Feb 2001 10:54:27 +0100

> same result if you're in the same directory.

Ok, that makes some sense. Having the client's pwd command return ""
for the home directory would definitely confuse users. Thanks for the
explanation.

/Niels

---

From: Jason R Thorpe <[email-masked]>
Date: Mon, 26 Feb 2001 08:19:08 -0800

> /usr/share even though `cd ..' lands you in /usr!)

That shell behavior is not specific to bash -- in fact, I seem to recall
that it is required by POSIX.

-- 
        -- Jason R. Thorpe <[email-masked]>

---

From: Andrew Brown <[email-masked]>
Date: Mon, 26 Feb 2001 11:57:31 -0500

>/usr/share even though `cd ..' lands you in /usr!)

tcsh can also do this, with the distinction that if you have this
feature turned on, after a "cd /usr/doc", then command "ls .." will be
executed as "ls /usr".  it's still not perfect though.

-- 
|-----< "CODE WARRIOR" >-----|
[email-masked]             * "ah!  i see you have the internet
[email-masked] (Andrew Brown)                that goes *ping*!"
[email-masked]       * "information is power -- share the wealth."

---

From: Markus Friedl <[email-masked]>
Date: Tue, 27 Feb 2001 14:19:32 +0100

> /usr/share even though `cd ..' lands you in /usr!)

oh yes, it's bad that chdir("..") and cd .. are not the
same.  this has been introduced with some ksh version.

see http://plan9.bell-labs.com/sys/doc/lexnames.{html,ps,pdf}
for related information.