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. > The question of how to display this in stat and tool is a different question > that can be left to the userspace developers. > > The UAPI headers uses Birth time language and stat displays: > > Access: 2026-11-02 15:22:27.067329367 +0100 > Modify: 2026-11-02 15:22:27.067329367 +0100 > Change: 2026-11-02 15:22:27.067329367 +0100 > Birth: 2026-11-02 15:22:27.067329367 +0100 > > If the UAPI headers will use consistent language: > > + /* provenance (settable creation) time */ > > + __s64 fa_ptime_sec; /* provenance (settable creation) time > (seconds) */ > > I think that the man pages could be unambiguous: > > stat(1) > %w time of file birth (immutable), human-readable; - if unknown > %W time of file birth (immutable), seconds since Epoch; 0 if unknown > %p time of file creation (mutable), human-readable; - if unknown > %P time of file creation (mutable), seconds since Epoch; 0 if unknown > > statx(2) > stx_btime > The file's (immutable) creation timestamp. > stx_ptime > The file's (mutable) creation timestamp. > > And userspace tools could be displaying ptime as: > > Access: 2026-11-02 15:22:27.067329367 +0100 > Modify: 2026-11-02 15:22:27.067329367 +0100 > Change: 2026-11-02 15:22:27.067329367 +0100 > Create: 2026-11-02 15:22:27.067329367 +0100 > Birth: 2026-11-02 15:22:27.067329367 +0100 > > If they want to, without that being more confusing than Provenance. That's fair, I don't like too much the fact that this would have a different name vs the variable name (as all other timestamps do), but it would be fine IMO. >> >> v2 changes: >> - fix permission bypass leading to ptime update on immutable and >> append-only files (found by sashiko[3]) >> - normalize ptime timestamp as done in fs/attr.c:notify_change() (found >> by sashiko[3]) >> - fix wording in vfs patch to be like the cover-letter >> >> v3 changes: >> - vfs: reject setting ptime with -EOPNOTSUPP on filesystems that do not >> support it instead of silently ignoring it (found by sashiko[4]) > > Please see my review on patch 1/5 on exporting the supported mask > to userspace. > >> - vfs: fix not being able to clear immutable and append-only on files >> with ptime, and allow updating immutable/append-only atomically along >> with ptime (found by sashiko[4]) >> - btrfs: validate on-disk ptime nanoseconds and reset to otime if >> invalid (found by sashiko[4]) >> - btrfs: avoid re-assigning ptime on unrelated chattr calls (found by >> sashiko[4]) >> - add ntfs3 and exfat support as suggested by Amir Goldstein[5], but no >> vfat, smb, or nfs4 yet as they are a bit more complex > > Please explain what makes them more complex. > My concern is that I would like to see that the proposed API fits the existing > fs and we won't need to change the API again later to support them. By "more complex" I mean just that when grepping the code I noticed ntfs and exfat were very straightforward to implement, while vfat had the msdos/non-msdos handling and smb had a completely different structure, so I thought it would be fine to have ntfs/exfat as proof-of-concepts at first. For v4 I can check and see how easy/difficult to implement ptime in smb and nfs (and vfat) is if you prefer, or keep that for v5 and v4 for the mask change. Thanks, koraynilay > Thanks, > Amir.