Am 19.10.20 um 23:43 schrieb Adam Borowski:
> On Mon, Oct 19, 2020 at 10:52:45PM +0200, Bernhard Übelacker wrote:
>> Dear Maintainer,
>> tried to track where the time is set/retrieved for a remote file
>> and came up with this location [1].
>>
>> I am not sure if flag
>> SSH_FILEXFER_ATTR_ACMODTIME/SSH2_FILEXFER_ATTR_ACMODTIME
>> is the only possible way ssh has to transfer the date, but at
>> least that way seems to just use 32 bits without the nano seconds.
>>
>> Unfortunately the "has no historic wire protocols" might not be
>> completely true because sshfs relies on ssh, which shows a similar
>> limitation also with sftp/scp.
>
> Looks like I've misread something, and such historic wire protocols indeed
> exist for sftp (which sshfs uses). On the other hand, they're long-expired
> drafts of the protocol.
>
> The granularity was 1s up to Draft 03:
> https://tools.ietf.org/html/draft-ietf-secsh-filexfer-03
> then changed to 1ns if SSH_FILEXFER_ATTR_SUBSECOND_TIMES is defined, in
> Draft 04:
> https://tools.ietf.org/html/draft-ietf-secsh-filexfer-04
>
> Thus, using that flag will stop timestamp truncation. (Well, programs that
> can't cope with truncated timestamps are buggy, but...)
>
> I have no idea if there are servers based on old drafts in the wild.
>
>
> Meow!
>
Unfortunately I failed to find any appearance of SUBSECOND in
the openssh-server source.
Looking in openssh bug tracker this bug might be interesting
and specifically mentions SSHFS:
https://bugzilla.mindrot.org/show_bug.cgi?id=1555
It mentions that "the patch" got included, but that seems just right
for the "l...@openssh.com"/"hardl...@openssh.com" part of the patches.
But the attr extension patches seem not to have applied upstream.
Kind regards,
Bernhard
