FAT32 File Creation/Birth Time Reporting Finally Comes To Linux

[Old Grouch]

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).

Without having a cryptographically secured link between a creation datetime and a trusted time source, creation dates can only ever be treated as fictive, although you might have a strong (and supportable) suspicion that they are correct. This does not mean that they are not useful. A nominal creation datetime, a nominal last-modified datetime, and a nominal last-accessed datetime are all attributes that can be useful to some people, especially if they can be relied upon. In addition the VMS operating system has an attribute of the datetime at which a file was last backed up. There could well be others. As a result, a case can be made for a generalization of datetime attributes that can be attached to a file, some of which ought to be standardized, such as nominal creation, modification, access, and backup datetimes, and others that could be defined by the user/programmer e.g. expiry date (beyond which the contents of the file must be treated as invalid), deletion date (which sounds odd, but knowing when a file was deleted from a system can be invaluable), erasure date (date when the file contents were randomized, or set to nulls or other data pattern), duplication dates (when a copy was made of the file)...and so on - possibly even have a 'restoration date' of the date a file was last restored from backup. Logically, the creation date of a file written to a backup tape is the date of the backup, which is separate to the inception date of the file.

An example would be:

Cause the file example.txt to come into existence.

The inception date is 2022-05-22 09:07

The creation date of this instance of the file is 2022-05-22 09:07
The backup date is nul
The restoral date is nul

Half an hour later I back up the file to a tape.
The inception date remains 2022-05-22 09:07

The creation date of this instance of the file (on the tape) is 2022-05-22 09:37
The backup date of the new instance of the file on the tape is nul because is has not been backed up.
The backup date of the original instance of the file on disk is modified from nul to 2022-05-22 09:37
The restoral date of this instance of the file (on the tape) is nul

15 minutes later I restore the file from tape to disk
The inception date remains 2022-05-22 09:07

The creation date of this new instance of the file (on the disk) is 2022-05-22 09:52.
The backup date of the new instance of the file on the disk is nul because this instance of the file has not been backed up.
The restoral date is 2022-05-22 09:52

Of course, what format the datetime stamp should take is open to confusion also: which calendar, what timezone, should it be cryptographically attested?

I routinely mount my filesystems as 'noatime', as it is not important to me to know when files were last accessed. People's use cases vary, so it would be good if the datetime attributes attached to files were flexible enough to accommodate the above use cases where necessary/required. Cryptographically attested access times could be quite a performance drain (!).

Other people will have their own views on the semantics of 'creation date'. Mine is not necessarily the correct one, applicable to all use cases.

[wikinevick]

FreeBSD has had it for over a decade now!

[Nth_man]

[...]
Other people will have their own views on the semantics of 'creation date'. Mine is not necessarily the correct one, applicable to all use cases.

Yes, although you have some good points there!

[edgmnt]

Why not preserve destination file creation time on rename, if it already exists? And for backups, tools already preserve extra metadata, so they could be expected to handle this stuff too.