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-0 2.66.0-2 ii openssh-client 1:8.3p1-1 sshfs recommends no packages. sshfs suggests no packages. -- no debconf information
