SFTP's handling of "." and ".."

[Damien Miller]

On Fri, 4 Jul 2025, Andrew Wood wrote:

> > I don't see the ambuguity here, the thing that will be transferred here
> > will always be the contents of whatever directory ../../foo resolves to
> > as sftp doesn't transfer symlinks (though maybe one day we'll get around
> > to implementing https://bugzilla.mindrot.org/show_bug.cgi?id=428)
> 
> My personal thinking is that in every other scenario than with . and
> .. the directory is uploaded along with the contents... not just the
> contents. In FreeBSD, at least, . and .. are not symbolic links, so
> I wouldn't expect them to be treated as symbolic links either. In my
> opinion, .and .. are special cases in how they need to be handled and
> when thinking about how to do so, we should think about what would
> happen in every other scenario, which is that the directory goes along
> with its contents. After all, one could just glob everything if they
> only wanted the contents.

Are you saying that you want "cd foo; put -r . bar" to create a
directory "foo/bar" and copy the contents of the current directory
into it?

If so, I don't think that is desirable and don't think it can be
done consistently.

It's not desirable because other tools don't behave that way, e.g.

[djm at djm ~]$ cd /tmp
[djm at djm tmp]$ mkdir a b
[djm at djm tmp]$ cd a
[djm at djm a]$ touch b c d
[djm at djm a]$ cp -vvr . /tmp/b
'./b' -> '/tmp/b/./b'
'./c' -> '/tmp/b/./c'
'./d' -> '/tmp/b/./d'

What tools do behave this way?

It can't be made consistent because of special cases including
"cd / ; put -r . bar". Also the sftp client may not have read
permissions on .. in all cases.

-d