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!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀
