using "synchronized" subsecond timestamps imho only makes sense with synchronized time (ntp) through that ssh tunnel, too. and with this assumption a "full VPN ssh usage" instead of "only filesystem timestamps" [maybe trying with target systems without subsecond timestamps?] seems impractical to me. or at least "... [sry, didnt have internet to send, incomplete but readable imho.] . la tero brulas! #VerdajDezertoj Saluton, Daja / Dahya unua NovaUNPrezident Am 21. Mai 2023 21:45:07 MESZ schrieb Demi Marie Obenour <demiobenour@xxxxxxxxx>: >On 5/10/23 08:50, Lucas Holt wrote: >> On 5/10/23 4:36 AM, Antonio Larrosa wrote: >>> Hello, >>> >>> This is probably a long email, but please bear with me. I plan to >>> submit a patch and would like to explain what I will do before doing >>> it so I don't lose time if there's some flaw in my plan. >>> >>> I currently use sshfs to mount directories from some computers and a >>> NAS into other computers. I recently noticed that when copying some >>> files from one computer into one of these sshfs mounted directories >>> (supposedly preserving times) the files are losing the subsecond part >>> of mtime (and atime). So, for example, `stat foo` shows this locally: >> >> My first thought after reading this is why aren't you using NFS? >> >> I can't speak to what patches might get accepted, but it does seem like >> this is the wrong tool for the job. > >Not sure what Antonio’s reason is, but using NFS securely is much harder >than SSH on all systems I know of, and impossible on OpenBSD without a VPN >tunnel. >-- >Sincerely, >Demi Marie Obenour (she/her/hers) _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
