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

[Nth_man]

Thinking about it...

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

if a file is copied from a NTFS partition, would "retaining the creation date" be correct (or misleading) for the new file? 🤔

[Joe2021]

That's what I was referring to. You mentioned the restoring of birth date. There is no general API to restore the birth date.

And there should not exist such an API, since the birth date is the time of the creation of the filesystem entry, and is not representing any semantics of your user purpose.

[Old Grouch]

Thinking about it...



if a file is copied from a NTFS partition, would "retaining the creation date" be correct (or misleading) for the new file? 🤔

If an NTFS partition is copied block-by-block to a new disk, should the creation dates of the files on the copied filesystem be changed to reflect the date of copying? 🤔

(The answer is clear if you think about it, but I'll leave it as a 'Student Exercise')

[billyswong]

For those who mourn against creation date:

People who are used to it and expect it coming from their Windows experience, want a date about when was the file created "locally" as a distinct object. They are NOT looking at when it was first written in the file system. They are treating the date similar to the date stored in EXIF metadata of digital photos, but with a twist. People expect/wish for software installation to mark the created files the date they install the program. But they expect/wish for personal zip archive extraction to retain the creation date before the content is being archived.

[Nth_man]

> > If a file is copied from a NTFS partition, would "retaining the creation date" be correct (or misleading) for the new file? 🤔

> [It would be correct]

Then, we can see that the creation date that the new file has... is not its creation date. Later, we can look for files that were created at that time, and several files are shown (but it's false, only one was created and that time).

Those are some examples of "Users 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)."

[Nth_man]

Creation time will still be usable only for a specific niche. On UNIX, it is common to replace a file instead of rewriting it. It is atomic and open files will not stop you from replacing it. It is the case for software updates but it might also happen with many more tools. For example, "sed -i" will create a new file, write the output and replace the original one.
-- Luiz Luca on https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1324454-linux-fat-file-creation-birth-time-reporting-proposal-for-statx-i-o-alignment-info?p=1324591#post1324591

[Errinwright]

Is this FS agnostic, and as such, would it be compatible with the upcoming BcacheFS?

[geerge]

Is this FS agnostic, and as such, would it be compatible with the upcoming BcacheFS?

It would allow a bcachefs implementation built using FUSE to use statx to implement birth times. It has no bearing on the bcachefs implementation queued for the kernel. The whole point of FUSE is implementing userspace filesystems, whether it's an actual filesystem or doing something like mounting some arbitrary archive format (perhaps to allow the-user/programs to access the contents of an archive without having to know the archive format).

[Danny3]

Thinking about it...



if a file is copied from a NTFS partition, would "retaining the creation date" be correct (or misleading) for the new file? 🤔

Retaing the "creation date" would be misleaging with the current structure of the file systems as none of them, AFAIK have two fields for this, as it would be required, like:

• Original-creation-date -> Which should be set to the date when the file was first created.
• Transferred-creattion-date -> Which should be set to the date when the file was copied / moved / restored (like from an archive / backup.

But for my case, I would like to have the creation date retained, even though it's fake / misleading as I want to know when the files were created on the NTFS partition, not when I copied / moved them on my EXT4 / BTRFS partition.

[coder]

And there should not exist such an API, since the birth date is the time of the creation of the filesystem entry, and is not representing any semantics of your user purpose.

There will always be people who want/expect to have backup/restore/mirror that's indistinguishable from the original, and there no real reason this shouldn't be possible.

IMO, it's not really the job of the OS to dictate what theses fields mean to the user. Rather, the OS should provide a sufficiently rich set of timestamps, which users can effectively adapt as they see fit. Build a wall and someone will invent a ladder. In on OSS system, absolute control over users is an ultimately futile pursuit.