FUSE Adds Initial Support For Statx, File Birth Times For File-Systems In User-Space

[phoronix]

Phoronix: FUSE Adds Initial Support For Statx, File Birth Times For File-Systems In User-Space

The Linux 6.6 FUSE driver code for enabling file-systems in user-space is adding support for STATX to the protocol as part of focusing on enabling file birth time "btime" support...

https://www.phoronix.com/news/Linux-6.6-FUSE

[Danny3]

Finally!
Hopefully not files copied / moved from / to NTFS partitions will retain the correct creation / modification / access dates.

[geerge]

The ordering in that struct makes me sad. There's probably a legit reason like backwards compatibility or whatever but still.

[avis]

Finally!
Hopefully not files copied / moved from / to NTFS partitions will retain the correct creation / modification / access dates.

I don't know a single Linux utility outside star which is capable of reading, storing or restoring the birth (creation) date and then star does it via its ar-se (by changing the system time). Modification and access dates have always worked when the noatime mount option is enabled.

Linux is quite something in terms of dealing with file dates. Anything outside the modification date has always been ignored.

[trapexit]

I don't know a single Linux utility outside star which is capable of reading, storing or restoring the birth (creation) date

Because it isn't a supported function of the filesystems via public APIs.

[Nth_man]

Backups are used to restore files. What is the "creation time" of a restored file?

This is a common case where the user is told a "creation time" that is not real. Can users trust what they are told? They must know all the circumstances of a file in order to trust that the creation time that they see is the real one. Only if requirements like that are met... a "creation time" is useful (instead of misleading).

[Joe2021]

Backups are used to restore files. What is the "creation time" of a restored file?

This is a common case where the user is told a "creation time" that is not real. Can users trust what they are told?

Yes, there should be a clear understanding of the semantics of such information, which is in this case from the perspective of the filesystem. It indicates the time of the filesystem event.

Btw you have the same situation with mtime, as a modification of a file on write is not guaranteed (nothing prevents to re-write the very same content to a file), which arises the question why modification time is updated when there actually was no modification.

[avis]

Because it isn't a supported function of the filesystems via public APIs.

statx() can read the birth date just fine. There's no API for setting the birth date, correct. No idea why it's never been added.

[Old Grouch]

Knowing the birth and modification dates of a file tells you precisely nothing about the age of the contents of the file. Presuming that they do is the cause of much muddled thinking. It is indeed possible to put old wine into new skins as well as new wine into old skins.

Generating and recording, in a tamper-proof manner, timestamps that can be relied upon is also a non-trivial problem.

[trapexit]

statx() can read the birth date just fine. There's no API for setting the birth date, correct. No idea why it's never been added.

That's what I was referring to. You mentioned the restoring of birth date. There is no general API to restore the birth date. Unless there was some way to ensure the value had meaning it isn't super valuable. You copy a file and rename over the original... what happens? You really need a vector, not scalar to be truly valuable and you'd need the system to ensure it doesn't get tampered with. All the *tim values should only ever be taken with a grain of salt even in controlled environments.