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 ⠈⠳⣄⠀⠀⠀⠀