Re: [RFC PATCH v1 0/6] provenance_time (ptime): a new settable timestamp for cross-filesystem provenance

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Apr 07, 2026 at 01:06:09AM -0500, Sean Smith wrote:
> 
> [written with AI assistance]
> 
> On 4/6/2026 20:42, Darrick J. Wong wrote:
> 
> > "Standard"... I was about to write a sardonic reply here, but then I
> > remembred that Linux finally *does* have a standard means to transfer
> > some of those newer file attributes: file_getattr/file_setattr.
> >
> > (Go Andrey!)
> >
> > So, I guess all you really need to do is extend struct file_attr and now
> > userspace has a fairly convenient means to propagate the provenance
> > time. 🙂
> 
> Thank you for pointing to file_getattr/file_setattr — this
> is a significantly better API path than our utimensat
> extension. The size-versioned struct file_attr eliminates
> the glibc times[2] limitation entirely, which was one of
> the main upstream concerns with the current approach.
> 
> We will investigate extending struct file_attr with ptime
> fields for v2. The on-disk storage across all 5 filesystems
> and the rename-over preservation are API-independent and
> would remain unchanged. The change is re-plumbing the
> userspace write path from utimensat to file_setattr.
> 
> Two design questions:
> 
> Would you recommend fa_ptime_sec (__u64) + fa_ptime_nsec
> (__u32) matching the statx timespec pattern, or a different
> representation?

That uses less space in the struct, so yes.

> Pali Rohar has announced plans for mask fields in file_attr.
> Should we coordinate with his mask work so ptime can be
> selectively set without read-modify-write?

fa_xflags already provides that coverage for the other fields in struct
file_attr, e.g. a getattr caller can ignore fa_extsize if
FS_XFLAG_EXTSIZE isn't set; and setattr will (iirc) reject nonzero
fa_extsize if FS_XFLAG_EXTSIZE isn't set.

Pali Rohar's work would make it possible to discover which fa_xflags
fields are settable or clearable for a given file.

> > So does the provenance time cover just the file's contents, or the other
> > attributes and xattrs?
> 
> Content only. ptime records when the file's data first came
> into existence. Metadata changes (permissions, owner,
> xattrs) update ctime but leave ptime unchanged. This
> matches the semantics of Windows Date Created and macOS
> creation time.
> 
> > The reason I ask is, does the ptime get copied over for an FICLONE,
> > which maps all of one file's data blocks into another?
> 
> It should, conceptually — the content's provenance doesn't
> change when you clone it. Currently FICLONE shares data
> extents but does not copy inode metadata (timestamps,
> permissions), so ptime would not be automatically
> preserved. The calling tool (e.g., cp --reflink) handles
> timestamp copying separately via the write path.
> 
> The question is whether FICLONE should be enhanced to copy
> ptime from source to destination at the kernel level —
> similar to how rename-over preserves ptime. There is an
> argument for it: if the kernel handles provenance during
> clone, tools don't need to know. But FICLONE doesn't
> currently copy mtime either, so adding ptime alone would
> be inconsistent. Worth discussing.

FICLONE is currently treated like a write, which means that mtime is
updated on the destination file.  For filesystems supporting ptime you'd
probably want the kernel to copy the ptime from src to dest after the
remapping completes.

(Same for exchange-range)

> Btrfs subvolume snapshots are a different case — they do
> preserve ptime because the inodes are COW copies of the
> originals.
> 
> > And by extension, would it also need to be exchanged if you told
> > XFS_IOC_EXCHANGE_RANGE to exchange all contents between two files?
> 
> Yes — if the content moves, the provenance should move
> with it. If files A and B exchange data extents, their
> ptimes should swap. ptime follows the content, not the
> inode identity.
> 
> > (I know, I know, you said XFS was TBDHBD ;))
> 
> Worth considering for a future XFS implementation — and
> the file_attr route you suggested would give XFS a clean
> integration path for ptime alongside FICLONE and
> EXCHANGE_RANGE.
> 
> > Last question: Is the provenance time only useful if the file is
> > immutable?  Either directly via chattr +i, or by enabling fsverity?
> 
> No — ptime is useful regardless of mutability. It records
> when the document was born, the same way Windows Date
> Created works. Editing a document updates mtime but not
> the creation date. Both are independently valuable:
> 
>   ptime: "This file was first created March 15, 2019"
>   mtime: "It was last modified today"
>   btime: "This inode was created when I copied it here"
> 
> Immutable files (chattr +i, fsverity) are a special case
> where ptime has extra forensic strength — the content
> provably hasn't changed since the provenance date. But for
> the primary use case — preserving creation dates across
> cross-platform migrations — mutability doesn't diminish
> ptime's value. A document's creation date remains meaningful
> regardless of subsequent edits.

Got it.

--D

> Sean
> 
> 
>