7 ms·

This brings up a related point that for the longest time (to my knowledge) Linux filesystems lacked creation timestamps, so only the last modified was preserved

This brings up a related point that for the longest time (to my knowledge) Linux filesystems lacked creation timestamps, so only the last modified was preserved. While even now with the filesystems that support them they're tied to that instance of the filesystem (ie: non-modifiable, unlike Windows), which has always puzzled me given the need to variously restore from backups (or just have an identical copy in a destination) where one would desire such info*. * When I last looked into this I saw some quite creative workarounds, such as a script loop where for each file to be copied it changed the system clock to the date of the timestamp, so it was recreated in the destination.

cb321 2y ago
This might interest you: https://github.com/c-blake/bu/blob/main/doc/cbtm.md Can save & restore both btime & ctime via "underhanded" filesystem debugging utility scripting. (It is in Nim which might be an obstacle for some, but honestly it is a very simple program to port to whatever.)
em-bee 2y ago
creation time is a nontrivial problem. when i copy a file to a new location (or unpack it from an archive, download it, etc...) is the creation time the time the file is saved or the time it was historically created. and if it is the first, and then you modify the file by making a copy of it and deleting the original (so the inode changes), does the creation time change, or should it be copied from the old version? so there are 4 different values: the original time when a file was originally created. the time when it was first created on this device. the time when a particular inode was created. the time when the content of the file was modified. and you could add more: if the file contains a story, how about the time the original story was written? or the time the content (and not the metadata, like the exif data of an image) was modified? there are use cases for each. but of all of them the last modified time is the easiest to reason about.
- Springtime 2y ago
  On NTFS (under Windows) it's handled rather straightforwardly. When a file is originally created it's given a date created timestamp. If the file is copied naively the date created timestamp changes to that of the copy time, while the date modified remains intact. However it's easy to preserve the date created timestamp during a copy using the native Robocopy utility, among many other methods. It's simply treated as date modified is: modifiable and arbitrary. This makes restoring from backups sensible. Have a drive that has died? Can do a file-based restore without the need for images and preserve such metadata. Individual file unexpectedly deleted? Restore it and regain the timestamps. The benefit is one has a transferable reference for when files were originally made, even if they lack internal metadata that stores this (such as eg: EXIF for images). Under Linux, even with its now kernel-based NTFS support, it just adds NTFS-specific data like date creation timestamps as peripheral extended attributes, which Linux file managers broadly don't expose or handle well. While native filesystems like EXT4 which support creation time are impractically limited to unmodifiable date creation timestamps based on their first creation on that particular instance of the filesystem, without hacky and fragile workarounds. That is despite `touch` being ubiquitous on Linux for modifying date modified timestamps (showing that in practical terms, it's considered similarly arbitrary metadata) which from what I've seen Linux users appear to have no disagreements with about its utility. As a Windows user who would like to migrate to Linux this aspect makes it frustratingly a non-starter, as even if one uses SMB to access the files (adding its own layer for such compatible metadata, regardless of the underlying filesystem) Linux file managers still don't handle well extended attributes so management for such files under Linux isn't at parity.

cb321 2y ago

This might interest you: https://github.com/c-blake/bu/blob/main/doc/cbtm.md Can save & restore both btime & ctime via "underhanded" filesystem debugging utility scripting. (It is in Nim which might be an obstacle for some, but honestly it is a very simple program to port to whatever.)

em-bee 2y ago

creation time is a nontrivial problem. when i copy a file to a new location (or unpack it from an archive, download it, etc...) is the creation time the time the file is saved or the time it was historically created. and if it is the first, and then you modify the file by making a copy of it and deleting the original (so the inode changes), does the creation time change, or should it be copied from the old version? so there are 4 different values: the original time when a file was originally created. the time when it was first created on this device. the time when a particular inode was created. the time when the content of the file was modified. and you could add more: if the file contains a story, how about the time the original story was written? or the time the content (and not the metadata, like the exif data of an image) was modified? there are use cases for each. but of all of them the last modified time is the easiest to reason about.

Springtime 2y ago
On NTFS (under Windows) it's handled rather straightforwardly. When a file is originally created it's given a date created timestamp. If the file is copied naively the date created timestamp changes to that of the copy time, while the date modified remains intact. However it's easy to preserve the date created timestamp during a copy using the native Robocopy utility, among many other methods. It's simply treated as date modified is: modifiable and arbitrary. This makes restoring from backups sensible. Have a drive that has died? Can do a file-based restore without the need for images and preserve such metadata. Individual file unexpectedly deleted? Restore it and regain the timestamps. The benefit is one has a transferable reference for when files were originally made, even if they lack internal metadata that stores this (such as eg: EXIF for images). Under Linux, even with its now kernel-based NTFS support, it just adds NTFS-specific data like date creation timestamps as peripheral extended attributes, which Linux file managers broadly don't expose or handle well. While native filesystems like EXT4 which support creation time are impractically limited to unmodifiable date creation timestamps based on their first creation on that particular instance of the filesystem, without hacky and fragile workarounds. That is despite `touch` being ubiquitous on Linux for modifying date modified timestamps (showing that in practical terms, it's considered similarly arbitrary metadata) which from what I've seen Linux users appear to have no disagreements with about its utility. As a Windows user who would like to migrate to Linux this aspect makes it frustratingly a non-starter, as even if one uses SMB to access the files (adding its own layer for such compatible metadata, regardless of the underlying filesystem) Linux file managers still don't handle well extended attributes so management for such files under Linux isn't at parity.