On 1/17/20 4:20 AM, Otto Moerbeek wrote:
On Thu, Jan 16, 2020 at 09:20:58PM -0800, William Ahern wrote:
On Thu, Jan 16, 2020 at 01:16:47PM +0100, Otto Moerbeek wrote:
On Thu, Jan 16, 2020 at 11:20:10AM +0000, gritzmann wrote:
Hi,
How do I change the birth time of a file? `touch -acm -d "1980-01-01 00:00:00"
myfile` changes only the access, modify and change times.
`stat myfile` returns `10 215746 -rw-r--r-- 1 me me 0 0 "Jan 1 00:00:00 1980" "Jan 1
00:00:00 1980" "Jan 16 13:00:33 2020" 16384 0 0 myfile`
Thanks!
Sent with ProtonMail Secure Email.
Change time != creation time. There is no such thing as creation time
in unix.
Not in Unix, but with UFS2 FreeBSD added birth time, which is documented
everywhere--including in source code--as being synonymous with "creation
time". OpenBSD added the st_birthtime field to struct stat in 2004,
https://cvsweb.openbsd.org/src/sys/sys/stat.h?rev=1.14&content-type=text/x-cvsweb-markup
https://github.com/openbsd/src/commit/cc2fc615c6e2dee87e5a3cd5a655a2ee5ef778c8
but as far as I can tell it's not set anywhere in the kernel.
FWIW, birth time has been adopted by ext4, ZFS, AFS, HAMMER2, and possibly
other file systems, but only the *BSDs seem to have added st_birthtime in
struct stat. On Linux it's stx_btime in struct statx, and as best I can tell
Solaris requires querying the A_CRTIME (creation time?) attribute using
getattrat. None of this is particularly relevant to OpenBSD, and I don't
mean to advocate, but after having done the leg work I feel like I should
commit this to an archive for posterity...
The change time (c_time in struct stat) cannot be explicitly set by
any API and is maintained by the kernel.
As far as I can tell from the FreeBSD man page for utimes and friends, this
is likewise true for birth time.
Thanks for this detailed extra info. I was vaguely aware that some
filesystem implementations have a creation time, but
- it is not in Posix and, even if *some* filesystems have it,
- there is no API to set it and no generally accepted API to get it.
-Otto
If these times were intended to help backup programs determine whether
a particular inode's content and attributes have changed since the last
backup (as I added and used them for backup purposes under TOPS-10)
then there must not be any way for any program to modify them. The kernel
must only change them if it changes the file in such a way that a backup
is out of date.
I suspect this is the reason for these fields. If not, they should be
used for that purpose.
