Re: A syscall for changing birth time

[Theodore Ts'o]

On Tue, Mar 11, 2025 at 05:08:39PM +0100, David Sterba wrote:
> 
> From my experience and use case: for archiving purposes the creation
> time has a meaning and it gets lost when the files get moved to bigger
> storage. Sometimes the creation is stored in the file metadata (like jpeg
> or video files), but ultimately the creation time is stored in the file
> inode metadata itself regardless of the format.
> 
> Another use case is for send/receive that transfers snapshots from one
> btrfs filesystem to another. In protocol v2 we added the creation time
> (otime) to the stream so the receiving side can read it, but cannot
> write it yet.
> 
> Question about ability to change otime/btime can be found around
> internet, there was attempt to make it a utimensat() operation
> (https://lore.kernel.org/linux-btrfs/cover.1550136164.git.osandov@xxxxxx).

How about this as a compromise?  We can define in statx two different
timestamp fields.  One is "btime" which is considered forensic
information which is not changeable by a system call interface, and
the other is "crtime" which *can* be changed by a system call
interface.  An individual file system is free to support one, or the
other, or both of these time stamp fields.

So file systems that come from the Windows world, including ntfs,
cifs, vfat, etc. can use crtime, and it can be set via some
standardized interface --- and file systems like xfs that want to
treat it as a non-changeable timestamp can only support btime.

What I might do with ext4 is to add a file system compat flag which
will cause the file system to support either crtime or btime, and
would use the on-dik inode field for one or the other.  That way I
don't break existing file system and potential use cases that want to
use btime, and allow those users who do want to use crtime in some of
the use cases that you've described to do so.  It does mean that a
single file system can only support "btime" or "crtime", but not both,
but it has the advantage that the semantics which are offered by a
particular file system are very clear --- and we don't have to gain
consensus across the various Linux file system maintainers about what
the One True Semantic for "btime/crttime" should be.  We can just have
both.

(And of course, some file systems might only support
mtime/ctime/atime, or only support a single timestamp value, and
that's also fine.)

						- Ted