On Tue Nov 3, 2026 at 4:12 PM CET, Amir Goldstein wrote: > On Tue, Nov 3, 2026 at 12:25 PM koraynilay wrote: >> >> On Mon Nov 2, 2026 at 3:54 PM CET, Amir Goldstein wrote: >> > On Sun, Nov 1, 2026 at 2:57 AM 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 >> >> >> >> 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). >> >> >> >> 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. >> > >> > FWIW, I agree that given the existing uses of btime and crtime in the >> > kernel and various XXXprogs, using 'ptime' for kernel code is probably >> > the lesser evil. >> >> What do you think about the origiN time (ntime) (Origin: in stat)? >> It would also coincidentally be alphabetically (ntime <-> mtime, n -> m) >> the same as btime <-> ctime (b -> c) ahah. >> > > Honestly I don't know. > My new idea is don't publish it in statx() at all. Well I was more talking about the actual variable names in all patches ahah. Thanks, koraynilay > Thanks, > Amir.