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

[Andrew Wood]

That's fair, I agree it should probably stay consistent to what other similar tools do. In that case your implementation is definitely better (I'd forgotten to consider absolute path usages in mine anyway).

> On Jul 7, 2025, at 1:45 AM, Damien Miller <djm at mindrot.org> wrote:
> 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