Re: [RFC PATCH v3 0/5] add provenance time (ptime)

["koraynilay" <koray.fra@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]

On Tue Nov 3, 2026 at 4:12 PM CET, Amir Goldstein wrote:
> On Tue, Nov 3, 2026 at 12:25 PM koraynilay <koray.fra@gmail.com> wrote:
>>
>> On Mon Nov 2, 2026 at 3:54 PM CET, Amir Goldstein wrote:
>> > On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> 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
>> >> <defendthedisabled@gmail.com> [1], but using
>> >> file_setattr()/file_getattr() as suggested by Darrick J. Wong
>> >> <djwong@kernel.org> 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.



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]