Bug#971645: sshfs: truncates timestamps to whole seconds
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
Bug#971645: sshfs: truncates timestamps to whole seconds
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.
Kind regards,
Bernhard
[1]
(rr) bt
#0 0x55c9a06ba46b in buf_get_attrs (buf=0x7f994b5d6b50,
stbuf=, flagsp=) at ../sshfs.c:912
#1 0x55c9a06bfe66 in sshfs_getattr (path=,
stbuf=0x7f994b5d6c80, fi=) at ../sshfs.c:3393
#2 0x55c9a06c184d in cache_getattr (fi=0x0, stbuf=0x7f994b5d6c80,
path=0x7f993c000c30 "/.bash_history") at ../cache.c:272
#3 cache_getattr (path=0x7f993c000c30 "/.bash_history",
stbuf=0x7f994b5d6c80, fi=0x0) at ../cache.c:266
#4 0x7f994c67a557 in lookup_path (f=0x55c9a07270e0, nodeid=1,
name=0x7f994a9d5038 ".bash_history", path=, e=0x7f994b5d6c70,
fi=) at ../lib/fuse.c:2537
#5 0x7f994c67a66b in fuse_lib_lookup (req=0x7f993c000b60, parent=1,
name=) at ../lib/fuse.c:2725
#6 0x7f994c687a83 in fuse_session_process_buf_int (se=0x55c9a07274b0,
buf=buf@entry=0x7f9944000b80, ch=) at ../lib/fuse_lowlevel.c:2666
#7 0x7f994c683393 in fuse_do_work (data=0x7f9944000b60) at
../lib/fuse_loop_mt.c:163
#8 0x7f994c655ea7 in start_thread (arg=) at
pthread_create.c:477
#9 0x7f994c456d4f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
866 if ((flags & SSH_FILEXFER_ATTR_ACMODTIME)) {
867 if (buf_get_uint32(buf, ) == -1 ||
868 buf_get_uint32(buf, ) == -1)
...
912 stbuf->st_ctime = stbuf->st_mtime = mtime;
[2]
benutzer@debian:~$ touch --date="2260-10-18 00:00:00.123456789"
/tmp/future-test-a
benutzer@debian:~$ scp -p benutzer@localhost:/tmp/future-test-a
/tmp/future-test-c
benutzer@localhost's password:
future-test-a
100%0 0.0KB/s 00:00
benutzer@debian:~$ sftp -p benutzer@localhost:/tmp/future-test-a
/tmp/future-test-b
benutzer@localhost's password:
Connected to localhost.
Fetching /tmp/future-test-a to /tmp/future-test-b
benutzer@debian:~$ ls -lisah --full-time /tmp/future-test*
70 0 -rw-r--r-- 1 benutzer benutzer 0 2260-10-18 00:00:00.123456789 +0200
/tmp/future-test-a
74 0 -rw-r--r-- 1 benutzer benutzer 0 1988-08-04 11:03:28.0 +0200
/tmp/future-test-b
73 0 -rw-r--r-- 1 benutzer benutzer 0 2260-10-18 00:00:00.0 +0200
/tmp/future-test-c
Bug#971645: sshfs: truncates timestamps to whole seconds
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. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#971645: sshfs: truncates timestamps to whole seconds
Package: sshfs Version: 3.7.0+repack-1 Severity: normal Hi! sshfs sets the sub-second part of timestamps to 0. This happens both on read (stat) and on write (utimensat). This means, the metadata of a file copied over sshfs will be different, causing unnecessary whole-file comparisons, etc. Strictly speaking, some historic filesystems have a large granularity (FAT has 2s...), but anything Unixy has standardized on 1ns since a long time ago, thus too many things assume timestamps to pass through uncorrupted. And sshfs has no historic wire protocols to care about, thus this piece of metadata loss doesn't seem intentional. Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-rc7-00045-g6b19fa129f99 (SMP w/64 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages sshfs depends on: ii fuse3 3.9.3-1 ii libc6 2.31-3 ii libfuse3-3 3.9.3-1 ii libglib2.0-02.66.0-2 ii openssh-client 1:8.3p1-1 sshfs recommends no packages. sshfs suggests no packages. -- no debconf information
