Date: Tue, 25 Jan 2022 02:54:00 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 261434] [fusefs] mtime and ctime changed on every read file Message-ID: <bug-261434-227-UAnTgXMy4J@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-261434-227@https.bugs.freebsd.org/bugzilla/> References: <bug-261434-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261434 --- Comment #12 from Ivan Rozhuk <rozhuk.im@gmail.com> --- (In reply to Alan Somers from comment #11) > Looking at the code you sent, sshfs_utimens is ignoring the tv_nsec field= , which is clearly a bug. I agree that libfuse+sshfs code is not clean, but sshfs MUST sent atime+mti= me in one message. https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-02 > The `atime' and `mtime' contain the access and modification times of > the files, respectively. They are represented as seconds from Jan 1, > 1970 in UTC. There is no place to nsec and magic values. > This is a bug in sshfs, and you should report it upstream. libfuse does not call utimens() in case UTIME_OMIT, as far I understand. I have no plans to report it. > Did your friend use "-o strictatime"? No, just -o atime. atime is updated in his tests, mtime is not. > Always sending mtime along with atime would be exactly the wrong thing fo= r the kernel to do. Only sending atime is what it's supposed to do. Another way is to get mtime/atime some where inside sshfs, probably sending additional requests, witch I do not like. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-261434-227-UAnTgXMy4J>