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

[Jan Kara]

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
> <defendthedisabled@xxxxxxxxx> [1], but using
> file_setattr()/file_getattr() as suggested by Darrick J. Wong
> <djwong@xxxxxxxxxx> 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

> 
> 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.
> 
> Thanks.
> 
> [1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@xxxxxxxxx
> [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
> 
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR