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

["Theodore Tso" <tytso@mit.edu>]

On Sun, Apr 05, 2026 at 02:49:56PM -0500, Sean Smith wrote:
> 
>   1. Application atomic saves destroy xattrs. Programs that save
>      via write-to-temp + rename() replace the inode, permanently
>      destroying all extended attributes. Only the VFS sees both
>      inodes during rename -- no userspace mechanism can intercept
>      this and copy metadata across.

The VFS could potentially copy the xattr on a rename, no?

>   2. Every tool in the copy chain must explicitly opt in to xattr
>      preservation. cp requires --preserve=xattr, rsync requires -X,
>      tar requires --xattrs. Each missing flag causes silent data
>      loss. Transparent preservation through arbitrary tool flows
>      is not achievable in userspace.

But this is true for your proposed ptime as well.  You have to change
every single tool to copy over the ptime.  Worse, you have to change
the format of tar in a non-standard on-disk format change to support
this new ptime timestamp.  And rsync will require a non-standard
protocol change to support the new timestamp.

> Atomic saves are the default behavior of mainstream applications
> (LibreOffice, Vim, Kate, etc.).

You will also have to change mainstream applications to copy ptime
from the original file to the file.new before the atomic rename.
Using ptime doesn't change this.  So you will need to make this
non-standard, Linux-specific change to all of these mainstream
applications.

Is it worth it?  It's a huge amount of cost being spread across a very
large part of the open source ecosystem just this fairly narrow use
case.  Personally, I'm not convinced it's worth the effort.

						- Ted