[RFC] Proposal: provenance_time (ptime) — a settable timestamp for cross-filesystem migration

[RFC] Proposal: provenance_time (ptime) — a settable timestamp for cross-filesystem migration

[Sean Smith]

[Email draft produced by AI agent. Reviewed, revised, and submitted by
Sean Smith.]

Hello,

I am writing as a user whose work is directly harmed by the absence
of a settable file creation timestamp in the Linux kernel. I am not a
kernel developer, but I believe this use case may help inform the
ongoing design discussion about btime semantics.

BACKGROUND

I am a disabled Medicaid recipient pursuing pro se civil rights
litigation against Tennessee's Medicaid program. I am building
a suite of AI tools for my litigation. These tools will include
an agentic document management system on Linux
(EndeavourOS/Arch).

My current workflow requires migrating terabytes of case law,
evidence, research, AI Harness project files, and other data
from NTFS (Windows) to Btrfs (Linux) and vice versa. These
documents span years of case history — some created as far
back as 2014.

I've used Windows exclusively for the past 20 years, and so I
have much to migrate. I am abandoning Windows because it has
repeatedly gotten in the way as I work in OpenCode and with
other AI tools. Linux offers a clearer path to using AI to
build a user-first future. My litigation relies upon my AI
agents and I developing effective AI tools and data systems.
This reliance makes the nonsense that has been going on with
Windows 11 an existential threat. People with disabilities
should not have to ask permission from the legal community or
corporations to have human rights; with an open-source suite
of AI litigation tools, they won't have to.

I provide the above context so that you may better understand
the importance of adopting my modest proposal.

When files are copied from NTFS to Btrfs, every file's creation
date is reset to the moment of the copy. The kernel provides no
syscall to restore the original creation timestamp. The result
is that files created in 2019 after transfer will report being
created in 2026.

For litigation evidence, file creation timestamps are provenance
metadata. They establish when a document first came into existence
as a digital file. Losing this metadata during a routine filesystem
migration is a forensic integrity failure — it destroys the timeline
that courts, investigators, and opposing counsel may rely on.

For humans and for AI agents, the loss of this metadata limits
how well they can navigate and retrieve from the corpus of
files.

THE PROBLEM AS I UNDERSTAND IT

Omar Sandoval submitted working patches in February 2019 (AT_UTIME_BTIME
for utimensat). They were not merged due to disagreement about whether
btime should be mutable.

The core dispute, as I understand it from the mailing list archives:

  - Dave Chinner (XFS): btime is forensic metadata — the moment the
    inode was allocated on this specific filesystem. Allowing it to
    be changed destroys its value for filesystem forensic analysis.

  - Ted Ts'o (ext4, March 2025): Proposed distinguishing "btime"
    (forensic, immutable) from "crtime" (settable, for migration
    and Windows compatibility).

  - David Sterba (Btrfs): Acknowledged the need, has a WIP for a
    Btrfs-specific ioctl to set otime. Noted btrfs send/receive
    protocol v2 transmits otime but cannot write it.

Both sides have legitimate points. The impasse exists because one
field is being asked to serve two incompatible purposes.

PROPOSAL: provenance_time (ptime)

I propose a new timestamp concept: provenance_time, abbreviated ptime.

ptime is distinct from btime:

  btime = "when was this inode born on THIS filesystem"
          Forensic. Immutable. Set by the kernel at inode creation.
          Valuable for filesystem forensic analysis and intrusion
          detection. Dave Chinner's use case is preserved.

  ptime = "when did this file's content first come into existence,
          on any filesystem, as reported by the earliest known source"
          User-settable. Designed for cross-filesystem migration,
          backup/restore, and provenance tracking. Travels with
          the file across copies.

This is similar to Ted Ts'o's btime/crtime split, but with clearer
semantics:

  - "crtime" (creation time) is easily confused with "ctime" (change
    time) and with btime itself. The word "creation" is ambiguous —
    creation of the inode, or creation of the content?

  - "ptime" (provenance time) is unambiguous. It explicitly
    communicates: this timestamp records provenance — where and
    when this file originated. It makes no claim about the local
    inode's birth. It does not conflict with btime's forensic
    meaning.

ptime fits naturally into the existing timestamp schema:

  atime  - access time
  mtime  - modification time
  ctime  - change time (metadata)
  btime  - birth time (inode, forensic, immutable)
  ptime  - provenance time (origin, settable, travels with file)

IMPLEMENTATION NOTES (from a user's perspective)

  - ptime should be settable via utimensat() or a new dedicated
    syscall, with appropriate privilege requirements (CAP_FOWNER
    or similar).

  - Filesystems that store a creation timestamp (ext4, btrfs, xfs,
    ntfs, exfat) could optionally support ptime using an additional
    inode field, or by allowing the existing crtime/otime field to
    serve as ptime when a filesystem-specific flag is set (as Ted
    suggested for ext4).

  - Standard tools (cp, rsync, tar) could be updated to read and
    write ptime, finally resolving the long-standing inability to
    preserve creation timestamps during file migration on Linux.

  - NTFS-originated filesystems could map their creation time to
    ptime, making Windows-to-Linux migration seamless.

WHO THIS AFFECTS

This is not a niche concern. In researching this issue, I found:

  - Backup/restore users (Duplicati, rsync, rclone all lose btime)
  - Windows-to-Linux migrators frustrated by silent metadata loss
  - Digital forensics professionals whose MACB timelines break
  - Data archivists and media librarians
  - Users with memory/accessibility needs who rely on creation
    dates to track personal document timelines
  - A developer on StackOverflow needing to process 1.3 million
    files with preserved timestamps — no solution available
  - A 7zip developer filing an issue (Feb 2026) documenting that
    Linux extraction cannot preserve creation times

The common thread across these use cases is that the current
impasse — where btime's forensic semantics block any settable
timestamp — produces worse forensic outcomes than providing a
clearly-separated settable field would. The provenance data is
being destroyed precisely because there is no sanctioned place
to put it.

ptime resolves this by giving that data a home without
compromising btime's forensic meaning.

Thank you for considering this proposal.

Sincerely,
Sean Smith
DefendTheDisabled.org

Re: [RFC] Proposal: provenance_time (ptime) — a settable timestamp for cross-filesystem migration

[Andreas Dilger]

On Mar 24, 2026, at 22:26, Sean Smith <defendthedisabled@gmail.com> wrote:
> 
> [Email draft produced by AI agent. Reviewed, revised, and submitted by
> Sean Smith.]
> 
> Hello,
> 
> I am writing as a user whose work is directly harmed by the absence
> of a settable file creation timestamp in the Linux kernel. I am not a
> kernel developer, but I believe this use case may help inform the
> ongoing design discussion about btime semantics.

Implementing a new timestamp for every filesystem is unlikely to happen
any time soon.  Even if the implementation was finished tomorrow, it
would be many years before a large number of users were running those
kernels, and tools had been modified to process the extra timestamps.


A simple solution that would work today would be to write a script for
Windows that extracted the creation time from NTFS and saved it as an
xattr on each file like "user.ptime" before they are copied to Linux.

Many tools today handle backup/restore and copying of xattrs already,
and since the goal of "ptime" is that it stays the same across copies,
then copying the xattr preserves the correct semantics with low effort.

The xattrs can be written in ASCII ISO8601 format like "date +%Is" does,
"2026-03-25T03:43:21-06:00", so that it sorts properly and is easily parsed.
It would be easy to set this via normal command-line tools on Linux, like:

$ setfattr -n user.ptime -v $(date -Is --date=@$(stat -c %W FILE)) FILE
$ getfattr -d -m user.ptime FILE
# file: FILE
user.ptime="2013-10-11T13:46:10-06:00"

to extract the (local) birth time in seconds, convert to ISO8601 format
and store it in the "user.ptime" xattr where it will stay unchanged.

To expand this further, you might consider submitting patches to Windows
tools (where file creation time can be set) like 7zip, rclone, etc.) to
save and restore the "user.ptime" xattr from creation time automatically.
If a few popular tools start doing this, it is more likely others would
follow suit.

Cheers, Andreas

Re: [RFC] Proposal: provenance_time (ptime) — a settable timestamp for cross-filesystem migration

[Simon Richter]

Hi,

On 3/25/26 1:26 PM, Sean Smith wrote:

> For litigation evidence, file creation timestamps are provenance
> metadata. They establish when a document first came into existence
> as a digital file. Losing this metadata during a routine filesystem
> migration is a forensic integrity failure — it destroys the timeline
> that courts, investigators, and opposing counsel may rely on.

FWIW, these creation timestamps are somewhat easily falsifiable -- by 
setting the system clock before creating the file, for example.

Adding another easily falsifiable timestamp that provides conflicting 
information does not help with forensic integrity, it only muddies the 
waters some more.

If you need to document that a file was created before a particular 
time, the proper approach is to submit a cryptographic checksum of the 
file to a timestamping service. There are various such services run by 
Certifying Authorities, some by notaries public, and some by volunteer 
organizations.

This does not help for older documents, obviously, because such a 
service would not attest to having seen the document on an older date 
than the present.

"Forensic" means that the file system metadata will be analyzed by an 
expert for plausibility. This expert will disbelieve any information, 
including "forensic" metadata, from any file system that was stored on 
media controlled by untrusted parties.

BSD has the concept of "securelevels", where even the admin user cannot 
perform certain actions while the system is running in multi-user mode, 
and direct modification of on-disk data bypassing the file system is 
among those. The key here is "multi-user mode": this is to protect 
against an attacker who has gained remote access destroying evidence.

The administrator is at any time free to switch the system to 
single-user mode, which locks out any remote access, perform any 
modifications they want, and return to multi-user mode. Because 
switching to single-user mode disrupts remote access, this manipulation 
level is unavailable to remote attackers, allowing the admin to perform 
"forensic" analysis after a breach.

This is only tangentially related to evidence presented at a trial. An 
expert witness can only state "this is the creation time I found on 
disk", but cannot say when that timestamp was written, so it is fairly 
weak evidence.

Timestamping services are much stronger: they have a system with 
physical access barriers that has a single interface to the outside 
world, over which it can receive a cryptographic checksum and return a 
cryptographically signed message with the data received, a timestamp, 
and a signature that covers both. This can be presented at court and, if 
necessary, supported by the witness testimony of the service operator.

In short, this is not a technical problem that can be solved on a 
computer that isn't trusted by the opposing party -- and the solution is 
to bring a trusted third party into the mix. There is a reason your 
lawyer stamps any letters they see with the current date.

    Simon

Re: [RFC] Proposal: provenance_time (ptime) — a settable timestamp for cross-filesystem migration

[Sean Smith]

Setting an xattr user.provenance_time was a solution my AI agents
and I arrived at for meeting my immediate Windows to Linux
migration needs. The idea to submit this ptime proposal was to
help the Linux kernel maintainers better understand the types of
problems that users like me encounter when switching to Linux.

Users like me are working with AI to solve previously neglected,
and untenable problems. I believe I am amongst the first of a wave of
disruptive projects that is going to hit many industries quite hard.

Users like me are unprecedented and working on unprecedented projects.
I think of my proposal being a bit of a heads-up to the Linux maintainers.
To help you plan for what's coming by understanding the vanguard of users
that are now arriving.

My intent with the proposal was to highlight:

1. The friction I encountered in Windows made the switch to Linux
*necessary*.

2. The friction in migrating to Linux can be reduced with simple,
long-overdue changes.

3. While ptime might not be effective proof of a files provenance in terms
of forensic computing, it is metadata that is critical to effective human
and agentic workflows.

Additionally, a sworn affidavit of authenticity is one way to assert the
date created is accurate file provenance. If the system administrator
knows the integrity of the metadata is sound, then they can attest
to that under oath. But if that metadata is destroyed, there is
nothing to attest to. The date created metadata can also be corroborated
by third parties. A plan beneficiary who records a phone call with
their insurer, and the insurer representative enters call notes into
a database. It's an event that 'happened'. With enough third-party data points
verifying a private dataset, the metadata becomes something a reasonable
person should believe to be accurate.

My point isn't to argue rules of evidence or debate how AI deep fakes
will require courts to exercise enhanced scrutiny. It's to illustrate
that the date created metadata has substantive value to legal work.
Additionally, that legal work is going to become an increasingly agentic
and pro se process that can supply substantive value to society by
enabling the under-served to access justice through an open-source
stack.

My proposal for provenance_time is more about reducing friction in migrating
to Linux and optimizing real-world workflows for humans and agents.

I concede that using xattr to add ptime will be effective, but it does
introduce operational inefficiencies and overhead. Overhead that I think
it worthwhile to be mindful of. Having every users AI agents coding up
an xattr fix for an obvious problem is a lot of wasted tokens and
human attention.

Sincerely,
Sean Smith
DefendTheDisabled.org