[Bug 272120] touch(1) -r modifies file's birthtime
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 272120] touch(1) -r modifies file's birthtime"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 272120] touch(1) -r modifies file's birthtime"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 272120] touch(1) -r modifies file's birthtime"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 21 Jun 2023 02:47:25 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272120
Bug ID: 272120
Summary: touch(1) -r modifies file's birthtime
Product: Base System
Version: 13.2-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: bugs@FreeBSD.org
Reporter: danfe@FreeBSD.org
touch(1) goes beyond what would one expect and what is documented in the
manpage:
-m Change the modification time of the file. The access time of
the file is not changed unless the -a flag is also specified.
-r Use the access and modifications times from the specified file
instead of the current time of day.
I'm seeing this on both UFS and ZFS:
$ cp -ai /some/real/file somefile
$ stat -x somefile | tail -4
Access: Sun Aug 11 22:06:44 2019
Modify: Sun Aug 11 22:06:48 2019 <-- created, written, closed
Change: Wed Jun 21 10:30:56 2023
Birth: Sun Aug 11 22:06:48 2019 <-- it's an old file
$ echo blah >> somefile
$ stat -x somefile | tail -4
Access: Sun Aug 11 22:06:44 2019
Modify: Wed Jun 21 10:31:21 2023 <-- we've just modified it
Change: Wed Jun 21 10:31:21 2023
Birth: Sun Aug 11 22:06:48 2019 <-- remains the same (correct)
$ touch -m -r /.rnd somefile <-- /.rnd is from 2014
$ stat -x somefile | tail -4
Access: Sun Aug 11 22:06:44 2019
Modify: Mon Jan 13 17:19:43 2014 <-- this is fine (expected)
Change: Wed Jun 21 10:31:42 2023
Birth: Mon Jan 13 17:19:43 2014 <-- WTF?!
--
You are receiving this mail because:
You are the assignee for the bug.