From: koraynilay <koray.fra@gmail.com>
To: David Sterba <dsterba@suse.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Namjae Jeon <linkinjeon@kernel.org>,
Sungjong Seo <sj1557.seo@samsung.com>,
Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Cc: "Chris Mason" <mason@kernel.org>, "Jan Kara" <jack@suse.cz>,
"Yuezhang Mo" <yuezhang.mo@sony.com>,
"Chuck Lever" <cel@kernel.org>,
"Darrick J . Wong" <djwong@kernel.org>,
"Sean Smith" <defendthedisabled@gmail.com>,
"Andrey Albershteyn" <aalbersh@kernel.org>,
"Pedro Falcato" <pfalcato@suse.de>,
"Amir Goldstein" <amir73il@gmail.com>,
"Pali Rohár" <pali@kernel.org>,
linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, exfat@lists.linux.dev,
ntfs3@lists.linux.dev, linux-api@vger.kernel.org,
koraynilay <koray.fra@gmail.com>
Subject: [RFC PATCH v3 0/5] add provenance time (ptime)
Date: Sun, 1 Nov 2026 02:55:46 +0100 [thread overview]
Message-ID: <20261101015551.786044-1-koray.fra@gmail.com> (raw)
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@gmail.com> [1], but using
file_setattr()/file_getattr() as suggested by Darrick J. Wong
<djwong@kernel.org> 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
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.
v2 changes:
- fix permission bypass leading to ptime update on immutable and
append-only files (found by sashiko[3])
- normalize ptime timestamp as done in fs/attr.c:notify_change() (found
by sashiko[3])
- fix wording in vfs patch to be like the cover-letter
v3 changes:
- vfs: reject setting ptime with -EOPNOTSUPP on filesystems that do not
support it instead of silently ignoring it (found by sashiko[4])
- vfs: fix not being able to clear immutable and append-only on files
with ptime, and allow updating immutable/append-only atomically along
with ptime (found by sashiko[4])
- btrfs: validate on-disk ptime nanoseconds and reset to otime if
invalid (found by sashiko[4])
- btrfs: avoid re-assigning ptime on unrelated chattr calls (found by
sashiko[4])
- add ntfs3 and exfat support as suggested by Amir Goldstein[5], but no
vfat, smb, or nfs4 yet as they are a bit more complex
- move the introduction of fileattr_has_fsx_mask() from the btrfs patch
to a standalone patch in the series
- btrfs: add fileattr_[gs]et to symlink and special file operations
Thanks.
[1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@gmail.com
[2]: https://lore.kernel.org/20260407014129.GC6192@frogsfrogsfrogs
[3]: https://sashiko.dev/#/patchset/20261027220532.736352-1-koray.fra%40gmail.com
[4]: https://sashiko.dev/#/patchset/20261028134728.294127-1-koray.fra%40gmail.com
[5]: https://lore.kernel.org/linux-btrfs/CAOQ4uxiuy0VwZj+3M-zRqQ49WTpHZpiaQ+6MZ8z8WdLjyQM_zA@mail.gmail.com/
koraynilay (5):
vfs: add provenance time (ptime)
vfs: add fileattr_has_fsx_mask()
ntfs3: make crtime user-settable using ptime
exfat: make crtime user-settable using ptime
btrfs: add provenance time (ptime)
fs/btrfs/btrfs_inode.h | 4 ++++
fs/btrfs/delayed-inode.c | 6 ++++++
fs/btrfs/inode.c | 29 +++++++++++++++++++++++++-
fs/btrfs/ioctl.c | 12 ++++++++++-
fs/btrfs/print-tree.c | 1 +
fs/btrfs/tree-log.c | 3 +++
fs/exfat/exfat_fs.h | 2 ++
fs/exfat/file.c | 36 ++++++++++++++++++++++++++++++++-
fs/exfat/namei.c | 1 +
fs/file_attr.c | 33 ++++++++++++++++++++++++++++--
fs/ntfs3/file.c | 14 +++++++++++--
fs/ntfs3/frecord.c | 8 +++++++-
fs/stat.c | 2 ++
include/linux/fileattr.h | 26 +++++++++++++++++++++---
include/linux/stat.h | 1 +
include/uapi/linux/btrfs_tree.h | 3 ++-
include/uapi/linux/fs.h | 8 +++++++-
include/uapi/linux/stat.h | 7 ++++++-
18 files changed, 182 insertions(+), 14 deletions(-)
base-commit: cbbddb6b08cc9900a87cccaa9b22bbe06aa4f50a
--
2.56.0
next reply other threads:[~2026-11-01 1:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 1:55 koraynilay [this message]
2026-11-01 1:55 ` [RFC PATCH v3 1/5] vfs: " koraynilay
2026-11-01 1:55 ` [RFC PATCH v3 2/5] vfs: add fileattr_has_fsx_mask() koraynilay
2026-11-01 1:55 ` [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime koraynilay
2026-11-01 1:55 ` [RFC PATCH v3 4/5] exfat: " koraynilay
2026-11-01 1:55 ` [RFC PATCH v3 5/5] btrfs: add provenance time (ptime) koraynilay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261101015551.786044-1-koray.fra@gmail.com \
--to=koray.fra@gmail.com \
--cc=aalbersh@kernel.org \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=cel@kernel.org \
--cc=defendthedisabled@gmail.com \
--cc=djwong@kernel.org \
--cc=dsterba@suse.com \
--cc=exfat@lists.linux.dev \
--cc=jack@suse.cz \
--cc=linkinjeon@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@kernel.org \
--cc=ntfs3@lists.linux.dev \
--cc=pali@kernel.org \
--cc=pfalcato@suse.de \
--cc=sj1557.seo@samsung.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yuezhang.mo@sony.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®