On Tue Nov 3, 2026 at 2:25 PM CET, Jan Kara wrote: > On Tue 27-10-26 23:05:30, koraynilay wrote: >> This is an initial implementation of a new timestamp to indicate the >> time when a file/directory was initially created. >> >> This patch series takes inspiration from the one by Sean Smith >> [1], but using >> file_setattr()/file_getattr() as suggested by Darrick J. Wong >> in [2]. >> >> The semantics of this new timestamp should be at least these: >> - it should be the same as btime on a newly created file >> - it's user-settable, so it can be preserved for backups, filesystem >> conversions, archives and any similar operation >> - it should be preserved every time mtime gets preserved >> >> and the correspondence with the other timestamps is as follows: >> >> ctime <-> btime >> mtime <-> ptime > > One thing I miss in this series is an explanation what this new timestamp is > good for. Because frankly, I don't miss such timestamp as a Linux user :). > > Honza Hello, my concrete use-cases are backups and filesystem conversions. For backups, my setup is btrfs and using btrbk (so btrfs send to my nas with ssh) and the only missing thing from the backup is the timestamp of file creation (which I'm currently working around using xattrs). The situation that prompted me to finally start working on this RFC PATCH was when I wanted to merge 2 btrfs FSs and the only way of doing that (AFAIK at least) is using cp/rsync, which can't set the creation time since btime is immutable. The workaround I used was the same as with backups, so with xattrs, but noticed that some files (symlinks) wouldn't accept xattrs, so I looked into it and found out xattrs are only for regular files/dirs. (also see https://lore.kernel.org/DMGS4KQLY24Q.14MUTR6U93GIC@gmail.com/) > >> >> Examples: >> 1) a .zsh_history file created in 2019, then after a few years the user >> decides to switch to another filesystem, copying the .zsh_history to >> the new home, in that case btime would have the timestamp of the copy >> and ptime would have the 2019 timestamp (just like mtime would have >> been preserved) >> 2) a symlink created in 2020 from the home directory to a /path going >> through the same process as the .zsh_history, in this case it would >> also make sense to sync the ptime to the 2020 timestamp instead of >> keeping only the btime (so the inode creation time). And as in these examples, keeping the original creation time for everything is valuable to some users (like me) and allows for a true 1:1 clone of files between filesystems without losing any metadata (I can't think of any other file metadata (not permissions) other than the creation time that is still missing). As for non-concrete use-cases, adding this timestamp would be good for completeness IMO, since the creation time of file data is not a thing on linux yet (but is on windows and mac). Thanks, koraynilay >> The proof-of-concept code (for testing) for stat(1) and cp(1) is >> available at https://github.com/koraynilay/coreutils (master branch) >> (Note: these coreutils code changes are a prototype and won't be >> submitted upstream as-is, but they work as expected in simple stat and >> cp -a/--preserve=ptime tests) >> >> Lastly, the name "provenance" and "ptime" are not final, I personally >> don't have a strong opinion on any name, but while testing with stat(1) >> I noticed that "Provenance" is definitely too long for the normal >> output, so another option which would fit well is "Origin time", >> abbreviated as "ntime" (OrigiN time) and not as "otime", as that would >> conflict with btrfs' internal naming and create confusion. >> >> Thanks. >> >> [1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@gmail.com >> [2]: https://lore.kernel.org/20260407014129.GC6192@frogsfrogsfrogs >> >> koraynilay (2): >> vfs: add provenance time (ptime) >> btrfs: add provenance time (ptime) >> >> fs/btrfs/btrfs_inode.h | 4 ++++ >> fs/btrfs/delayed-inode.c | 6 ++++++ >> fs/btrfs/inode.c | 17 ++++++++++++++++- >> fs/btrfs/ioctl.c | 12 +++++++++++- >> fs/btrfs/print-tree.c | 1 + >> fs/btrfs/tree-log.c | 3 +++ >> fs/file_attr.c | 24 ++++++++++++++++++++++-- >> fs/stat.c | 2 ++ >> include/linux/fileattr.h | 27 ++++++++++++++++++++++++--- >> include/linux/stat.h | 1 + >> include/uapi/linux/btrfs_tree.h | 3 ++- >> include/uapi/linux/fs.h | 8 +++++++- >> include/uapi/linux/stat.h | 7 ++++++- >> 13 files changed, 105 insertions(+), 10 deletions(-) >> >> >> base-commit: 21a7f44fd0765fcc5194130b28767786eba1d1e7 >> -- >> 2.56.0 >>