Date: Fri, 26 Jun 2026 12:09:30 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 272120] touch(1) -r modifies file's birthtime Message-ID: <bug-272120-227-k5V4g6OJrT@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-272120-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272120 --- Comment #5 from Alexey Dokuchaev <danfe@FreeBSD.org> --- (In reply to Simon Tettmar from comment #4) > [VFS] deliberately sets va_birthtime to the requested mtime when the > requested mtime is earlier than the current birthtime. I've been thinking about this since when Mark had made his analysis in comment #2, and could not come to peace with the rationale behind existing behavior. > I cannot convince myself that having mtimes prior to birthtimes can ever > be a good thing and so if no one objects I will look at updating touch(1) > documentation to explain this behaviour. I don't quite see why these timestamps should be interconnected at all. Inode birth time should be constant throughout the inode's life, due to the mere definition of birth. Non-constant birth time is semantically wrong. Modification time applies to file contents which has nothing to do with its container's inode. I guess I see the value of better describing current (bogus) behavior to reduce user confusion, but I'll probably start patching my kernels to stop messing with btimes after they were assigned. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-272120-227-k5V4g6OJrT>