[RFC PATCH v3 0/5] add provenance time (ptime)

[RFC PATCH v3 0/5] add provenance time (ptime)

[koraynilay]

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

[RFC PATCH v3 1/5] vfs: add provenance time (ptime)

[koraynilay]

Add provenance time (ptime), indicating the time when a file or
directory was created. This is user-settable via file_setattr() and
retrievable via statx(2) (using STATX_PTIME) or file_getattr().

The semantics of when to preserve this new timestamp are the same as
mtime, the idea being that there is a correspondence like this:

ctime <-> btime
mtime <-> ptime

so every operation (copying, moving, ...) that currently preserves mtime
should also preserve ptime.

Furthermore, in order to avoid the legacy FS_IOC_FSSETXATTR accepting
FS_XFLAG_PTIME, add an FS_FILE_ATTR_XFLAGS_MASK mask to support new
xflags, and use it in fileattr_to_file_attr()/file_attr_to_fileattr() to
allow ptime to be used with the file_setattr()/file_getattr() syscalls.

[ This is a re-implementation of the initial patch[1] by Sean Smith
  <defendthedisabled@gmail.com>, following the advice[2] from Darrick J.
  Wong <djwong@kernel.org> of using file_setattr() instead of updating
  utimensat() ]

[1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@gmail.com
[2]: https://lore.kernel.org/20260407014129.GC6192@frogsfrogsfrogs

Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
Signed-off-by: koraynilay <koray.fra@gmail.com>
---
 fs/file_attr.c            | 33 +++++++++++++++++++++++++++++++--
 fs/stat.c                 |  2 ++
 include/linux/fileattr.h  |  5 +++++
 include/linux/stat.h      |  1 +
 include/uapi/linux/fs.h   |  8 +++++++-
 include/uapi/linux/stat.h |  7 ++++++-
 6 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/fs/file_attr.c b/fs/file_attr.c
index 833e03810b24..c0645cb22bf3 100644
--- a/fs/file_attr.c
+++ b/fs/file_attr.c
@@ -102,7 +102,7 @@ EXPORT_SYMBOL(vfs_fileattr_get);
 static void fileattr_to_file_attr(const struct file_kattr *fa,
 				  struct file_attr *fattr)
 {
-	__u32 mask = FS_XFLAGS_MASK;
+	__u32 mask = FS_FILE_ATTR_XFLAGS_MASK;
 
 	memset(fattr, 0, sizeof(struct file_attr));
 	fattr->fa_xflags = fa->fsx_xflags & mask;
@@ -110,6 +110,8 @@ static void fileattr_to_file_attr(const struct file_kattr *fa,
 	fattr->fa_nextents = fa->fsx_nextents;
 	fattr->fa_projid = fa->fsx_projid;
 	fattr->fa_cowextsize = fa->fsx_cowextsize;
+	fattr->fa_ptime_sec = fa->fsx_ptime.tv_sec;
+	fattr->fa_ptime_nsec = fa->fsx_ptime.tv_nsec;
 }
 
 /**
@@ -141,15 +143,20 @@ EXPORT_SYMBOL(copy_fsxattr_to_user);
 static int file_attr_to_fileattr(const struct file_attr *fattr,
 				 struct file_kattr *fa)
 {
-	__u64 mask = FS_XFLAGS_MASK;
+	__u64 mask = FS_FILE_ATTR_XFLAGS_MASK;
 
 	if (fattr->fa_xflags & ~mask)
 		return -EINVAL;
 
+	if (fattr->fa_pad != 0)
+		return -EINVAL;
+
 	fileattr_fill_xflags(fa, fattr->fa_xflags & ~FS_XFLAG_RDONLY_MASK);
 	fa->fsx_extsize = fattr->fa_extsize;
 	fa->fsx_projid = fattr->fa_projid;
 	fa->fsx_cowextsize = fattr->fa_cowextsize;
+	fa->fsx_ptime.tv_sec = fattr->fa_ptime_sec;
+	fa->fsx_ptime.tv_nsec = fattr->fa_ptime_nsec;
 
 	return 0;
 }
@@ -232,6 +239,20 @@ static int fileattr_set_prepare(struct inode *inode,
 	    !S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode))
 		return -EINVAL;
 
+	if (fa->fsx_xflags & FS_XFLAG_PTIME) {
+		if (!(old_ma->fsx_xflags & FS_XFLAG_PTIME))
+			return -EOPNOTSUPP;
+
+		if ((unsigned long)fa->fsx_ptime.tv_nsec >= NSEC_PER_SEC)
+			return -EINVAL;
+
+		fa->fsx_ptime = timestamp_truncate(fa->fsx_ptime, inode);
+
+		if (!timespec64_equal(&old_ma->fsx_ptime, &fa->fsx_ptime) &&
+		    (fa->flags & old_ma->flags) & (FS_APPEND_FL | FS_IMMUTABLE_FL))
+			return -EPERM;
+	}
+
 	/*
 	 * It is only valid to set the DAX flag on regular files and
 	 * directories on filesystems.
@@ -293,6 +314,7 @@ int vfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
 			fa->fsx_nextents = old_ma.fsx_nextents;
 			fa->fsx_projid = old_ma.fsx_projid;
 			fa->fsx_cowextsize = old_ma.fsx_cowextsize;
+			fa->fsx_ptime = old_ma.fsx_ptime;
 		} else {
 			fa->flags |= old_ma.flags & ~FS_COMMON_FL;
 		}
@@ -423,6 +445,10 @@ SYSCALL_DEFINE5(file_getattr, int, dfd, const char __user *, filename,
 		return error;
 
 	fileattr_to_file_attr(&fa, &fattr);
+
+	if (usize < FILE_ATTR_SIZE_VER1)
+		fattr.fa_xflags &= ~FS_XFLAG_PTIME;
+
 	error = copy_struct_to_user(ufattr, usize, &fattr,
 				    sizeof(struct file_attr), NULL);
 
@@ -459,6 +485,9 @@ SYSCALL_DEFINE5(file_setattr, int, dfd, const char __user *, filename,
 	if (error)
 		return error;
 
+	if ((fattr.fa_xflags & FS_XFLAG_PTIME) && usize < FILE_ATTR_SIZE_VER1)
+		return -EINVAL;
+
 	error = file_attr_to_fileattr(&fattr, &fa);
 	if (error)
 		return error;
diff --git a/fs/stat.c b/fs/stat.c
index a2e63c6c45b7..e426f41253f6 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -728,6 +728,8 @@ cp_statx(const struct kstat *stat, struct statx __user *buffer)
 	tmp.stx_ctime.tv_nsec = stat->ctime.tv_nsec;
 	tmp.stx_mtime.tv_sec = stat->mtime.tv_sec;
 	tmp.stx_mtime.tv_nsec = stat->mtime.tv_nsec;
+	tmp.stx_ptime.tv_sec = stat->ptime.tv_sec;
+	tmp.stx_ptime.tv_nsec = stat->ptime.tv_nsec;
 	tmp.stx_rdev_major = MAJOR(stat->rdev);
 	tmp.stx_rdev_minor = MINOR(stat->rdev);
 	tmp.stx_dev_major = MAJOR(stat->dev);
diff --git a/include/linux/fileattr.h b/include/linux/fileattr.h
index 09e32b84e02a..0b93f9609284 100644
--- a/include/linux/fileattr.h
+++ b/include/linux/fileattr.h
@@ -35,6 +35,10 @@
 	(FS_XFLAG_COMMON | FS_XFLAG_RDONLY_MASK | FS_XFLAG_VALUES_MASK | \
 	 FS_XFLAG_DIRONLY_MASK | FS_XFLAG_MISC_MASK)
 
+/* Flags only for fa_ fields */
+#define FS_FILE_ATTR_XFLAGS_MASK \
+	(FS_XFLAGS_MASK | FS_XFLAG_PTIME)
+
 /*
  * Merged interface for miscellaneous file attributes.  'flags' originates from
  * ext* and 'fsx_flags' from xfs.  There's some overlap between the two, which
@@ -49,6 +53,7 @@ struct file_kattr {
 	u32	fsx_nextents;	/* nextents field value (get)	*/
 	u32	fsx_projid;	/* project identifier (get/set) */
 	u32	fsx_cowextsize;	/* CoW extsize field value (get/set)*/
+	struct timespec64 fsx_ptime; /* provenance (settable birth) time */
 	/* selectors: */
 	bool	flags_valid:1;
 	bool	fsx_valid:1;
diff --git a/include/linux/stat.h b/include/linux/stat.h
index 9c5709132862..69d2ecfd1bf2 100644
--- a/include/linux/stat.h
+++ b/include/linux/stat.h
@@ -48,6 +48,7 @@ struct kstat {
 	struct timespec64 mtime;
 	struct timespec64 ctime;
 	struct timespec64 btime;			/* File creation time */
+	struct timespec64 ptime;	/* File provenance (user-settable creation) time */
 	u64		blocks;
 	u64		mnt_id;
 	u64		change_cookie;
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index a46c33692aa2..c00e72fcfa3e 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -229,10 +229,14 @@ struct file_attr {
 	__u32 fa_nextents;	/* nextents field value (get)   */
 	__u32 fa_projid;	/* project identifier (get/set) */
 	__u32 fa_cowextsize;	/* CoW extsize field value (get/set) */
+	__s64 fa_ptime_sec;	/* provenance (settable birth) time (seconds) */
+	__u32 fa_ptime_nsec;	/* provenance (settable birth) time (nanoseconds) */
+	__u32 fa_pad;
 };
 
 #define FILE_ATTR_SIZE_VER0 24
-#define FILE_ATTR_SIZE_LATEST FILE_ATTR_SIZE_VER0
+#define FILE_ATTR_SIZE_VER1 40
+#define FILE_ATTR_SIZE_LATEST FILE_ATTR_SIZE_VER1
 
 /*
  * Flags for the fsx_xflags field
@@ -261,6 +265,8 @@ struct file_attr {
  */
 #define FS_XFLAG_CASEFOLD	0x00040000	/* case-insensitive lookups */
 #define FS_XFLAG_CASENONPRESERVING 0x00080000	/* case not preserved */
+
+#define FS_XFLAG_PTIME		0x00100000	/* provenance time */
 #define FS_XFLAG_HASATTR	0x80000000	/* no DIFLAG for this	*/
 
 /* the read-only stuff doesn't really belong here, but any other place is
diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
index 1686861aae20..f3a1013ba022 100644
--- a/include/uapi/linux/stat.h
+++ b/include/uapi/linux/stat.h
@@ -187,7 +187,11 @@ struct statx {
 	__u32	__spare2[1];
 
 	/* 0xc0 */
-	__u64	__spare3[8];	/* Spare space for future expansion */
+	/* Data provenance (creation) time */
+	struct statx_timestamp	stx_ptime;
+
+	/* 0xd0 */
+	__u64	__spare3[6];	/* Spare space for future expansion */
 
 	/* 0x100 */
 };
@@ -219,6 +223,7 @@ struct statx {
 #define STATX_SUBVOL		0x00008000U	/* Want/got stx_subvol */
 #define STATX_WRITE_ATOMIC	0x00010000U	/* Want/got atomic_write_* fields */
 #define STATX_DIO_READ_ALIGN	0x00020000U	/* Want/got dio read alignment info */
+#define STATX_PTIME		0x00040000U	/* Want/got stx_ptime */
 
 #define STATX__RESERVED		0x80000000U	/* Reserved for future struct statx expansion */
 
-- 
2.56.0

[RFC PATCH v3 2/5] vfs: add fileattr_has_fsx_mask()

[koraynilay]

Add fileattr_has_fsx_mask() as a helper to let filesystems check for
unsupported xflags while allowing supported ones. Can be used in the
same way as fileattr_has_fsx().

Also make fileattr_has_fsx() a wrapper around fileattr_has_fsx_mask().

Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
Signed-off-by: koraynilay <koray.fra@gmail.com>
---
 include/linux/fileattr.h | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/include/linux/fileattr.h b/include/linux/fileattr.h
index 0b93f9609284..16acc61c9af1 100644
--- a/include/linux/fileattr.h
+++ b/include/linux/fileattr.h
@@ -64,6 +64,23 @@ int copy_fsxattr_to_user(const struct file_kattr *fa, struct fsxattr __user *ufa
 void fileattr_fill_xflags(struct file_kattr *fa, u32 xflags);
 void fileattr_fill_flags(struct file_kattr *fa, u32 flags);
 
+/**
+ * fileattr_has_fsx_mask - check for extended flags/attributes
+ * @fa:				fileattr pointer
+ * @allowed_xflags_mask:	additional xflags permitted
+ *
+ * Return: true if any attributes are present that are not represented in
+ * ->flags or @allowed_xflags_mask.
+ */
+static inline bool fileattr_has_fsx_mask(const struct file_kattr *fa,
+					 u32 allowed_xflags_mask)
+{
+	return fa->fsx_valid &&
+		((fa->fsx_xflags & ~(FS_XFLAG_COMMON | allowed_xflags_mask)) ||
+		 fa->fsx_extsize != 0 || fa->fsx_projid != 0 ||
+		 fa->fsx_cowextsize != 0);
+}
+
 /**
  * fileattr_has_fsx - check for extended flags/attributes
  * @fa:		fileattr pointer
@@ -73,9 +90,7 @@ void fileattr_fill_flags(struct file_kattr *fa, u32 flags);
  */
 static inline bool fileattr_has_fsx(const struct file_kattr *fa)
 {
-	return fa->fsx_valid &&
-		((fa->fsx_xflags & ~FS_XFLAG_COMMON) || fa->fsx_extsize != 0 ||
-		 fa->fsx_projid != 0 ||	fa->fsx_cowextsize != 0);
+	return fileattr_has_fsx_mask(fa, 0);
 }
 
 int vfs_fileattr_get(struct dentry *dentry, struct file_kattr *fa);
-- 
2.56.0

[RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[koraynilay]

Since NTFS supports user-settable file creation timestamps, map
provenance time (ptime) to NTFS file creation time (crtime) by using the
newly introduced ptime API (in commit "vfs: add provenance time
(ptime)").

To do this, update ntfs_fileattr_[gs]et(), ntfs_getattr() and make it
persist to disk in ni_write_inode().

The timestamp is now retrievable by using file_getattr() or statx(), and
is settable by using file_setattr() with the FS_XFLAG_PTIME flag.

Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
Signed-off-by: koraynilay <koray.fra@gmail.com>
---
 fs/ntfs3/file.c    | 14 ++++++++++++--
 fs/ntfs3/frecord.c |  8 +++++++-
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/fs/ntfs3/file.c b/fs/ntfs3/file.c
index 1624f9b014e0..b334449e9beb 100644
--- a/fs/ntfs3/file.c
+++ b/fs/ntfs3/file.c
@@ -124,6 +124,10 @@ int ntfs_fileattr_get(struct dentry *dentry, struct file_kattr *fa)
 
 	fileattr_fill_flags(fa, flags);
 
+	fa->fsx_ptime.tv_sec = ni->i_crtime.tv_sec;
+	fa->fsx_ptime.tv_nsec = ni->i_crtime.tv_nsec;
+	fa->fsx_xflags |= FS_XFLAG_PTIME;
+
 	return 0;
 }
 
@@ -142,7 +146,7 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
 	if (unlikely(is_bad_ni(ni)))
 		return -EINVAL;
 
-	if (fileattr_has_fsx(fa))
+	if (fileattr_has_fsx_mask(fa, FS_XFLAG_PTIME))
 		return -EOPNOTSUPP;
 
 	if (flags & ~(FS_IMMUTABLE_FL | FS_APPEND_FL | FS_NODUMP_FL))
@@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
 	if (flags & FS_APPEND_FL)
 		new_fl |= S_APPEND;
 
+	if (fa->fsx_xflags & FS_XFLAG_PTIME) {
+		ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
+		ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
+	}
+
 	inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
 
 	/* Save nodump flag to return in ntfs_getattr. */
@@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
 	if (unlikely(is_bad_ni(ni)))
 		return -EINVAL;
 
-	stat->result_mask |= STATX_BTIME;
+	stat->result_mask |= (STATX_BTIME | STATX_PTIME);
 	stat->btime = ni->i_crtime;
+	stat->ptime = ni->i_crtime;
 	stat->blksize = ni->mi.sbi->cluster_size; /* 512, 1K, ..., 2M */
 
 	if (inode->i_flags & S_IMMUTABLE)
diff --git a/fs/ntfs3/frecord.c b/fs/ntfs3/frecord.c
index 16ac847de48d..5e4f743a5930 100644
--- a/fs/ntfs3/frecord.c
+++ b/fs/ntfs3/frecord.c
@@ -3215,6 +3215,13 @@ int ni_write_inode(struct inode *inode, int sync, const char *hint)
 		}
 
 		/* Update the access times if they have changed. */
+		ts = ni->i_crtime;
+		dup.cr_time = kernel2nt(&ts);
+		if (std->cr_time != dup.cr_time) {
+			std->cr_time = dup.cr_time;
+			modified = true;
+		}
+
 		ts = inode_get_mtime(inode);
 		dup.m_time = kernel2nt(&ts);
 		if (std->m_time != dup.m_time) {
@@ -3250,7 +3257,6 @@ int ni_write_inode(struct inode *inode, int sync, const char *hint)
 		    (modified || (ni->ni_flags & NI_FLAG_UPDATE_PARENT))
 		    /* Avoid __wait_on_freeing_inode(inode). */
 		    && (sb->s_flags & SB_ACTIVE)) {
-			dup.cr_time = std->cr_time;
 			/* Not critical if this function fail. */
 			re_dirty = ni_update_parent(ni, &dup, sync);
 
-- 
2.56.0

[RFC PATCH v3 4/5] exfat: make crtime user-settable using ptime

[koraynilay]

Since exFAT supports user-settable file creation timestamps, map
provenance time (ptime) to exFAT file creation time (crtime) using the
newly introduced ptime API (in commit "vfs: add provenance time
(ptime)").

To do this, implement exfat_fileattr_set(), set .fileattr_set to it for
both file_inode and dir_inode operations and update exfat_fileattr_get()
and exfat_getattr().

The timestamp is now retrievable by using file_getattr() or statx(), and
is settable by using file_setattr() with the FS_XFLAG_PTIME flag.

Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
Signed-off-by: koraynilay <koray.fra@gmail.com>
---
 fs/exfat/exfat_fs.h |  2 ++
 fs/exfat/file.c     | 36 +++++++++++++++++++++++++++++++++++-
 fs/exfat/namei.c    |  1 +
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h
index eee573d1697c..aff96afa258a 100644
--- a/fs/exfat/exfat_fs.h
+++ b/fs/exfat/exfat_fs.h
@@ -619,6 +619,8 @@ int exfat_getattr(const struct mnt_idmap *idmap, const struct path *path,
 		  unsigned int query_flags);
 struct file_kattr;
 int exfat_fileattr_get(struct dentry *dentry, struct file_kattr *fa);
+int exfat_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
+		       struct file_kattr *fa);
 int exfat_file_fsync(struct file *file, loff_t start, loff_t end, int datasync);
 long exfat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
 long exfat_compat_ioctl(struct file *filp, unsigned int cmd,
diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index 1386149916bb..70e226cb4ab7 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -384,15 +384,20 @@ int exfat_getattr(const struct mnt_idmap *idmap, const struct path *path,
 
 	generic_fillattr(idmap, request_mask, inode, stat);
 	exfat_truncate_atime(&stat->atime);
-	stat->result_mask |= STATX_BTIME;
+	stat->result_mask |= (STATX_BTIME | STATX_PTIME);
 	stat->btime.tv_sec = ei->i_crtime.tv_sec;
 	stat->btime.tv_nsec = ei->i_crtime.tv_nsec;
+	stat->ptime.tv_sec = ei->i_crtime.tv_sec;
+	stat->ptime.tv_nsec = ei->i_crtime.tv_nsec;
 	stat->blksize = EXFAT_SB(inode->i_sb)->cluster_size;
 	return 0;
 }
 
 int exfat_fileattr_get(struct dentry *dentry, struct file_kattr *fa)
 {
+	struct inode *inode = d_backing_inode(dentry);
+	struct exfat_inode_info *ei = EXFAT_I(inode);
+
 	/*
 	 * exFAT compares filenames through an upcase table, so lookup
 	 * is always case-insensitive. Long names are stored in UTF-16
@@ -400,6 +405,11 @@ int exfat_fileattr_get(struct dentry *dentry, struct file_kattr *fa)
 	 */
 	fa->fsx_xflags |= FS_XFLAG_CASEFOLD;
 	fa->flags |= FS_CASEFOLD_FL;
+
+	fa->fsx_ptime.tv_sec = ei->i_crtime.tv_sec;
+	fa->fsx_ptime.tv_nsec = ei->i_crtime.tv_nsec;
+	fa->fsx_xflags |= FS_XFLAG_PTIME;
+
 	return 0;
 }
 
@@ -485,6 +495,29 @@ int exfat_setattr(const struct mnt_idmap *idmap, struct dentry *dentry,
 	return error;
 }
 
+int exfat_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
+		      struct file_kattr *fa)
+{
+	struct inode *inode = d_backing_inode(dentry);
+	struct exfat_inode_info *ei = EXFAT_I(inode);
+
+	if (fileattr_has_fsx_mask(fa, FS_XFLAG_PTIME))
+		return -EOPNOTSUPP;
+
+	if (fa->flags & ~FS_CASEFOLD_FL)
+		return -EOPNOTSUPP;
+
+	if (fa->fsx_xflags & FS_XFLAG_PTIME) {
+		ei->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
+		ei->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
+	}
+
+	inode_set_ctime_current(inode);
+	mark_inode_dirty(inode);
+
+	return 0;
+}
+
 /*
  * modified ioctls from fat/file.c by Welmer Almesberger
  */
@@ -1110,4 +1143,5 @@ const struct inode_operations exfat_file_inode_operations = {
 	.setattr	= exfat_setattr,
 	.getattr	= exfat_getattr,
 	.fileattr_get	= exfat_fileattr_get,
+	.fileattr_set	= exfat_fileattr_set,
 };
diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index 68ddb9c5504f..15ec7f1942c8 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -1349,4 +1349,5 @@ const struct inode_operations exfat_dir_inode_operations = {
 	.setattr	= exfat_setattr,
 	.getattr	= exfat_getattr,
 	.fileattr_get	= exfat_fileattr_get,
+	.fileattr_set	= exfat_fileattr_set,
 };
-- 
2.56.0

[RFC PATCH v3 5/5] btrfs: add provenance time (ptime)

[koraynilay]

Implement provenance time (ptime) in Btrfs, as introduced in a
previous commit ("vfs: add provenance time (ptime)").

Update the on-disk format by claiming 12 bytes from the reserved[] space
in btrfs_inode_item, putting ptime before other timestamps.

Also, set .fileattr_[gs]et to btrfs_fileattr_[gs]et() for both
symlinks and special files.

Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
Signed-off-by: koraynilay <koray.fra@gmail.com>
---
 fs/btrfs/btrfs_inode.h          |  4 ++++
 fs/btrfs/delayed-inode.c        |  6 ++++++
 fs/btrfs/inode.c                | 29 ++++++++++++++++++++++++++++-
 fs/btrfs/ioctl.c                | 13 ++++++++++++-
 fs/btrfs/print-tree.c           |  1 +
 fs/btrfs/tree-log.c             |  3 +++
 include/uapi/linux/btrfs_tree.h |  3 ++-
 7 files changed, 56 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 0782f917fccc..c9822340567a 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -332,6 +332,10 @@ struct btrfs_inode {
 	u64 i_otime_sec;
 	u32 i_otime_nsec;
 
+	/* File *data* creation (provenance) time. */
+	s64 i_ptime_sec;
+	u32 i_ptime_nsec;
+
 	/* Hook into fs_info->delayed_iputs */
 	struct list_head delayed_iput;
 
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 333ce8b52489..eef73ebb4a52 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1932,6 +1932,9 @@ static void fill_stack_inode_item(struct btrfs_trans_handle *trans,
 
 	btrfs_set_stack_timespec_sec(&inode_item->otime, inode->i_otime_sec);
 	btrfs_set_stack_timespec_nsec(&inode_item->otime, inode->i_otime_nsec);
+
+	btrfs_set_stack_timespec_sec(&inode_item->ptime, inode->i_ptime_sec);
+	btrfs_set_stack_timespec_nsec(&inode_item->ptime, inode->i_ptime_nsec);
 }
 
 int btrfs_fill_inode(struct btrfs_inode *inode, u32 *rdev)
@@ -1981,6 +1984,9 @@ int btrfs_fill_inode(struct btrfs_inode *inode, u32 *rdev)
 	inode->i_otime_sec = btrfs_stack_timespec_sec(&inode_item->otime);
 	inode->i_otime_nsec = btrfs_stack_timespec_nsec(&inode_item->otime);
 
+	inode->i_ptime_sec = btrfs_stack_timespec_sec(&inode_item->ptime);
+	inode->i_ptime_nsec = btrfs_stack_timespec_nsec(&inode_item->ptime);
+
 	vfs_inode->i_generation = inode->generation;
 	if (S_ISDIR(vfs_inode->i_mode))
 		inode->index_cnt = (u64)-1;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index abaa33471456..6ac7fa774ccf 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4057,6 +4057,17 @@ static int btrfs_read_locked_inode(struct btrfs_inode *inode, struct btrfs_path
 	inode->i_otime_sec = btrfs_timespec_sec(leaf, &inode_item->otime);
 	inode->i_otime_nsec = btrfs_timespec_nsec(leaf, &inode_item->otime);
 
+	inode->i_ptime_sec = btrfs_timespec_sec(leaf, &inode_item->ptime);
+	inode->i_ptime_nsec = btrfs_timespec_nsec(leaf, &inode_item->ptime);
+	/* Avoid old garbage on-disk data making btrfs load a bad value */
+	if (unlikely(inode->i_ptime_nsec >= NSEC_PER_SEC)) {
+		btrfs_warn(fs_info,
+			   "invalid ptime.nsec %u on ino %llu from disk, setting ptime to otime",
+			   inode->i_ptime_nsec, btrfs_ino(inode));
+		inode->i_ptime_sec = inode->i_otime_sec;
+		inode->i_ptime_nsec = inode->i_otime_nsec;
+	}
+
 	inode_set_bytes(vfs_inode, btrfs_inode_nbytes(leaf, inode_item));
 	inode->generation = btrfs_inode_generation(leaf, inode_item);
 	inode->last_trans = btrfs_inode_transid(leaf, inode_item);
@@ -4249,6 +4260,9 @@ static void fill_inode_item(struct btrfs_trans_handle *trans,
 	btrfs_set_timespec_sec(leaf, &item->otime, BTRFS_I(inode)->i_otime_sec);
 	btrfs_set_timespec_nsec(leaf, &item->otime, BTRFS_I(inode)->i_otime_nsec);
 
+	btrfs_set_timespec_sec(leaf, &item->ptime, BTRFS_I(inode)->i_ptime_sec);
+	btrfs_set_timespec_nsec(leaf, &item->ptime, BTRFS_I(inode)->i_ptime_nsec);
+
 	btrfs_set_inode_nbytes(leaf, item, inode_get_bytes(inode));
 	btrfs_set_inode_generation(leaf, item, BTRFS_I(inode)->generation);
 	btrfs_set_inode_sequence(leaf, item, inode_peek_iversion(inode));
@@ -5988,6 +6002,8 @@ static struct btrfs_inode *new_simple_dir(struct inode *dir,
 	inode_set_atime_to_ts(vfs_inode, inode_get_atime(dir));
 	inode->i_otime_sec = ts.tv_sec;
 	inode->i_otime_nsec = ts.tv_nsec;
+	inode->i_ptime_sec = ts.tv_sec;
+	inode->i_ptime_nsec = ts.tv_nsec;
 
 	vfs_inode->i_uid = dir->i_uid;
 	vfs_inode->i_gid = dir->i_gid;
@@ -6714,6 +6730,8 @@ int btrfs_create_new_inode(struct btrfs_trans_handle *trans,
 	ts = simple_inode_init_ts(inode);
 	BTRFS_I(inode)->i_otime_sec = ts.tv_sec;
 	BTRFS_I(inode)->i_otime_nsec = ts.tv_nsec;
+	BTRFS_I(inode)->i_ptime_sec = ts.tv_sec;
+	BTRFS_I(inode)->i_ptime_nsec = ts.tv_nsec;
 
 	/*
 	 * We're going to fill the inode item now, so at this point the inode
@@ -8048,6 +8066,9 @@ struct inode *btrfs_alloc_inode(struct super_block *sb)
 	ei->i_otime_sec = 0;
 	ei->i_otime_nsec = 0;
 
+	ei->i_ptime_sec = 0;
+	ei->i_ptime_nsec = 0;
+
 	inode = &ei->vfs_inode;
 	btrfs_extent_map_tree_init(&ei->extent_tree);
 
@@ -8186,9 +8207,11 @@ static int btrfs_getattr(const struct mnt_idmap *idmap,
 	u32 blocksize = btrfs_sb(inode->i_sb)->sectorsize;
 	u32 bi_flags = BTRFS_I(inode)->flags;
 
-	stat->result_mask |= STATX_BTIME;
+	stat->result_mask |= (STATX_BTIME | STATX_PTIME);
 	stat->btime.tv_sec = BTRFS_I(inode)->i_otime_sec;
 	stat->btime.tv_nsec = BTRFS_I(inode)->i_otime_nsec;
+	stat->ptime.tv_sec = BTRFS_I(inode)->i_ptime_sec;
+	stat->ptime.tv_nsec = BTRFS_I(inode)->i_ptime_nsec;
 	if (bi_flags & BTRFS_INODE_APPEND)
 		stat->attributes |= STATX_ATTR_APPEND;
 	if (bi_flags & BTRFS_INODE_COMPRESS)
@@ -10779,6 +10802,8 @@ static const struct inode_operations btrfs_special_inode_operations = {
 	.get_inode_acl	= btrfs_get_acl,
 	.set_acl	= btrfs_set_acl,
 	.update_time	= btrfs_update_time,
+	.fileattr_get	= btrfs_fileattr_get,
+	.fileattr_set	= btrfs_fileattr_set,
 };
 static const struct inode_operations btrfs_symlink_inode_operations = {
 	.get_link	= page_get_link,
@@ -10787,6 +10812,8 @@ static const struct inode_operations btrfs_symlink_inode_operations = {
 	.permission	= btrfs_permission,
 	.listxattr	= btrfs_listxattr,
 	.update_time	= btrfs_update_time,
+	.fileattr_get	= btrfs_fileattr_get,
+	.fileattr_set	= btrfs_fileattr_set,
 };
 
 const struct dentry_operations btrfs_dentry_operations = {
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index f3e2afe221be..dfcf710d828c 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -275,6 +275,9 @@ int btrfs_fileattr_get(struct dentry *dentry, struct file_kattr *fa)
 	const struct btrfs_inode *inode = BTRFS_I(d_inode(dentry));
 
 	fileattr_fill_flags(fa, btrfs_inode_flags_to_fsflags(inode));
+	fa->fsx_ptime.tv_sec = inode->i_ptime_sec;
+	fa->fsx_ptime.tv_nsec = inode->i_ptime_nsec;
+	fa->fsx_xflags |= FS_XFLAG_PTIME;
 	return 0;
 }
 
@@ -294,7 +297,11 @@ int btrfs_fileattr_set(const struct mnt_idmap *idmap,
 	if (btrfs_root_readonly(root))
 		return -EROFS;
 
-	if (fileattr_has_fsx(fa))
+	/*
+	 * We now support FS_XFLAG_PTIME, so exclude it from the unsupported
+	 * check
+	 */
+	if (fileattr_has_fsx_mask(fa, FS_XFLAG_PTIME))
 		return -EOPNOTSUPP;
 
 	fsflags = btrfs_mask_fsflags_for_type(&inode->vfs_inode, fa->flags);
@@ -436,6 +443,10 @@ int btrfs_fileattr_set(const struct mnt_idmap *idmap,
 	}
 
 update_flags:
+	if (!fa->flags_valid && (fa->fsx_xflags & FS_XFLAG_PTIME)) {
+		inode->i_ptime_sec = fa->fsx_ptime.tv_sec;
+		inode->i_ptime_nsec = fa->fsx_ptime.tv_nsec;
+	}
 	inode->flags = inode_flags;
 	btrfs_update_inode_mapping_flags(inode);
 	btrfs_sync_inode_flags_to_i_flags(inode);
diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
index 53e726119ca7..ba385d0ed9ed 100644
--- a/fs/btrfs/print-tree.c
+++ b/fs/btrfs/print-tree.c
@@ -263,6 +263,7 @@ static void print_inode_item(const struct extent_buffer *eb, int i)
 	print_timespec(eb, &ii->ctime, "\t\tctime ", "\n");
 	print_timespec(eb, &ii->mtime, "\t\tmtime ", "\n");
 	print_timespec(eb, &ii->otime, "\t\totime ", "\n");
+	print_timespec(eb, &ii->ptime, "\t\tptime ", "\n");
 }
 
 static void print_dir_item(const struct extent_buffer *eb, int i)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 1d9dfb63fc5a..72a4a92b40b9 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4631,6 +4631,9 @@ static void fill_inode_item(struct btrfs_trans_handle *trans,
 	btrfs_set_timespec_sec(leaf, &item->otime, inode->i_otime_sec);
 	btrfs_set_timespec_nsec(leaf, &item->otime, inode->i_otime_nsec);
 
+	btrfs_set_timespec_sec(leaf, &item->ptime, inode->i_ptime_sec);
+	btrfs_set_timespec_nsec(leaf, &item->ptime, inode->i_ptime_nsec);
+
 	/*
 	 * We do not need to set the nbytes field, in fact during a fast fsync
 	 * its value may not even be correct, since a fast fsync does not wait
diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
index 47ee52859b45..c360b3e95f45 100644
--- a/include/uapi/linux/btrfs_tree.h
+++ b/include/uapi/linux/btrfs_tree.h
@@ -900,7 +900,8 @@ struct btrfs_inode_item {
 	 * a little future expansion, for more than this we can
 	 * just grow the inode item and version it
 	 */
-	__le64 reserved[4];
+	__le32 reserved[5];
+	struct btrfs_timespec ptime;
 	struct btrfs_timespec atime;
 	struct btrfs_timespec ctime;
 	struct btrfs_timespec mtime;
-- 
2.56.0

Re: [RFC PATCH v3 1/5] vfs: add provenance time (ptime)

[Amir Goldstein]

On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> wrote:
>
> Add provenance time (ptime), indicating the time when a file or
> directory was created. This is user-settable via file_setattr() and
> retrievable via statx(2) (using STATX_PTIME) or file_getattr().
>
> The semantics of when to preserve this new timestamp are the same as
> mtime, the idea being that there is a correspondence like this:
>
> ctime <-> btime
> mtime <-> ptime
>
> so every operation (copying, moving, ...) that currently preserves mtime
> should also preserve ptime.
>
> Furthermore, in order to avoid the legacy FS_IOC_FSSETXATTR accepting
> FS_XFLAG_PTIME, add an FS_FILE_ATTR_XFLAGS_MASK mask to support new
> xflags, and use it in fileattr_to_file_attr()/file_attr_to_fileattr() to
> allow ptime to be used with the file_setattr()/file_getattr() syscalls.
>
> [ This is a re-implementation of the initial patch[1] by Sean Smith
>   <defendthedisabled@gmail.com>, following the advice[2] from Darrick J.
>   Wong <djwong@kernel.org> of using file_setattr() instead of updating
>   utimensat() ]
>
> [1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@gmail.com
> [2]: https://lore.kernel.org/20260407014129.GC6192@frogsfrogsfrogs
>
> Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
> Signed-off-by: koraynilay <koray.fra@gmail.com>
> ---
>  fs/file_attr.c            | 33 +++++++++++++++++++++++++++++++--
>  fs/stat.c                 |  2 ++
>  include/linux/fileattr.h  |  5 +++++
>  include/linux/stat.h      |  1 +
>  include/uapi/linux/fs.h   |  8 +++++++-
>  include/uapi/linux/stat.h |  7 ++++++-
>  6 files changed, 52 insertions(+), 4 deletions(-)
>
> diff --git a/fs/file_attr.c b/fs/file_attr.c
> index 833e03810b24..c0645cb22bf3 100644
> --- a/fs/file_attr.c
> +++ b/fs/file_attr.c
> @@ -102,7 +102,7 @@ EXPORT_SYMBOL(vfs_fileattr_get);
>  static void fileattr_to_file_attr(const struct file_kattr *fa,
>                                   struct file_attr *fattr)
>  {
> -       __u32 mask = FS_XFLAGS_MASK;
> +       __u32 mask = FS_FILE_ATTR_XFLAGS_MASK;
>
>         memset(fattr, 0, sizeof(struct file_attr));
>         fattr->fa_xflags = fa->fsx_xflags & mask;
> @@ -110,6 +110,8 @@ static void fileattr_to_file_attr(const struct file_kattr *fa,
>         fattr->fa_nextents = fa->fsx_nextents;
>         fattr->fa_projid = fa->fsx_projid;
>         fattr->fa_cowextsize = fa->fsx_cowextsize;
> +       fattr->fa_ptime_sec = fa->fsx_ptime.tv_sec;
> +       fattr->fa_ptime_nsec = fa->fsx_ptime.tv_nsec;
>  }
>
>  /**
> @@ -141,15 +143,20 @@ EXPORT_SYMBOL(copy_fsxattr_to_user);
>  static int file_attr_to_fileattr(const struct file_attr *fattr,
>                                  struct file_kattr *fa)
>  {
> -       __u64 mask = FS_XFLAGS_MASK;
> +       __u64 mask = FS_FILE_ATTR_XFLAGS_MASK;

That is not the correct way to extend this API.
This fixed mask was added as a placeholder for
"We intend to add support for more xflags to selective filesystems":
https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-2-amir73il@gmail.com/

Please see this POC patch for filesystems to publish their supported
xflags mask:
https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-3-amir73il@gmail.com/

This will allow callers of file_getattr() to know if the filesystem
supports ptime
without trying to set it and failing.

Thanks,
Amir.

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Pali Rohár]

On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
>  	if (flags & FS_APPEND_FL)
>  		new_fl |= S_APPEND;
>  
> +	if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> +		ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> +		ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> +	}
> +
>  	inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
>  
>  	/* Save nodump flag to return in ntfs_getattr. */
> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
>  	if (unlikely(is_bad_ni(ni)))
>  		return -EINVAL;
>  
> -	stat->result_mask |= STATX_BTIME;
> +	stat->result_mask |= (STATX_BTIME | STATX_PTIME);
>  	stat->btime = ni->i_crtime;
> +	stat->ptime = ni->i_crtime;

For me this patch looks dangerous. Somehow I would expect that the
"btime" will never change for existing inode.

But because the ptime is mapped to i_crtime and ptime is settable from
userspace, with this patch it is directly possible to change btime.



I was thinking more about it... Is not this just misunderstanding of how
the security model around the times is working on different systems?
Because on NTFS there is stored just one field which says when the file
was created. There are not two fields like "time set by user and time
set by system".

Windows security model allows anybody with WRITE_ATTRIBUTES access to
change that create time. Linux security model does not allow to change it.

NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
In my opinion if the ext4 or btrfs filesystem is correctly implemented
on Windows systems, then Windows security model should handle it in the
same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
access, then Windows should allow to change also btime on ext4 or btrfs.



On the other hand, I understand the use case to have two creation times.
One time which would never be changed and could be used for any kind of
atomic / synchronization by userspace application logic (this btime).
And another time for human which can be changed at any time to any value
which user wants (this ptime).

In any case, I would suggest that filesystem driver would not report to
userspace unsupported values and would not try to invent other values
and lying about them.

Re: [RFC PATCH v3 0/5] add provenance time (ptime)

[Amir Goldstein]

On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> wrote:
>
> 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.

FWIW, I agree that given the existing uses of btime and crtime in the
kernel and various XXXprogs, using 'ptime' for kernel code is probably
the lesser evil.

The question of how to display this in stat and tool is a different question
that can be left to the userspace developers.

The UAPI headers uses Birth time language and stat displays:

Access: 2026-11-02 15:22:27.067329367 +0100
Modify: 2026-11-02 15:22:27.067329367 +0100
Change: 2026-11-02 15:22:27.067329367 +0100
 Birth: 2026-11-02 15:22:27.067329367 +0100

If the UAPI headers will use consistent language:

+       /* provenance (settable creation) time */

+       __s64 fa_ptime_sec;     /* provenance (settable creation) time
(seconds) */

I  think that the man pages could be unambiguous:

stat(1)
       %w     time of file birth (immutable), human-readable; - if unknown
       %W    time of file birth (immutable), seconds since Epoch; 0 if unknown
       %p     time of file creation (mutable), human-readable; - if unknown
       %P     time of file creation (mutable), seconds since Epoch; 0 if unknown

statx(2)
       stx_btime
              The file's (immutable) creation timestamp.
       stx_ptime
              The file's (mutable) creation timestamp.

And userspace tools could be displaying ptime as:

Access: 2026-11-02 15:22:27.067329367 +0100
Modify: 2026-11-02 15:22:27.067329367 +0100
Change: 2026-11-02 15:22:27.067329367 +0100
Create: 2026-11-02 15:22:27.067329367 +0100
 Birth: 2026-11-02 15:22:27.067329367 +0100

If they want to, without that being more confusing than Provenance.

>
> 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])

Please see my review on patch 1/5 on exporting the supported mask
to userspace.

> - 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

Please explain what makes them more complex.
My concern is that I would like to see that the proposed API fits the existing
fs and we won't need to change the API again later to support them.

Thanks,
Amir.

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Amir Goldstein]

On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> > @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> >       if (flags & FS_APPEND_FL)
> >               new_fl |= S_APPEND;
> >
> > +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> > +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> > +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> > +     }
> > +
> >       inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> >
> >       /* Save nodump flag to return in ntfs_getattr. */
> > @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> >       if (unlikely(is_bad_ni(ni)))
> >               return -EINVAL;
> >
> > -     stat->result_mask |= STATX_BTIME;
> > +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> >       stat->btime = ni->i_crtime;
> > +     stat->ptime = ni->i_crtime;
>
> For me this patch looks dangerous. Somehow I would expect that the
> "btime" will never change for existing inode.
>
> But because the ptime is mapped to i_crtime and ptime is settable from
> userspace, with this patch it is directly possible to change btime.
>
>
>
> I was thinking more about it... Is not this just misunderstanding of how
> the security model around the times is working on different systems?
> Because on NTFS there is stored just one field which says when the file
> was created. There are not two fields like "time set by user and time
> set by system".
>
> Windows security model allows anybody with WRITE_ATTRIBUTES access to
> change that create time. Linux security model does not allow to change it.
>
> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> In my opinion if the ext4 or btrfs filesystem is correctly implemented
> on Windows systems, then Windows security model should handle it in the
> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> access, then Windows should allow to change also btime on ext4 or btrfs.
>
>
>
> On the other hand, I understand the use case to have two creation times.
> One time which would never be changed and could be used for any kind of
> atomic / synchronization by userspace application logic (this btime).
> And another time for human which can be changed at any time to any value
> which user wants (this ptime).
>
> In any case, I would suggest that filesystem driver would not report to
> userspace unsupported values and would not try to invent other values
> and lying about them.

But all those fs with mutable creation time already report it with STATX_BTIME
so what can we do about this?

If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
those fs could technically return only STATX_PTIME and it should not regress
existing programs.

But this is still a bit surprising behavior is it not?

Thanks,
Amir.

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Pali Rohár]

On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> > > @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> > >       if (flags & FS_APPEND_FL)
> > >               new_fl |= S_APPEND;
> > >
> > > +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> > > +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> > > +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> > > +     }
> > > +
> > >       inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> > >
> > >       /* Save nodump flag to return in ntfs_getattr. */
> > > @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> > >       if (unlikely(is_bad_ni(ni)))
> > >               return -EINVAL;
> > >
> > > -     stat->result_mask |= STATX_BTIME;
> > > +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> > >       stat->btime = ni->i_crtime;
> > > +     stat->ptime = ni->i_crtime;
> >
> > For me this patch looks dangerous. Somehow I would expect that the
> > "btime" will never change for existing inode.
> >
> > But because the ptime is mapped to i_crtime and ptime is settable from
> > userspace, with this patch it is directly possible to change btime.
> >
> >
> >
> > I was thinking more about it... Is not this just misunderstanding of how
> > the security model around the times is working on different systems?
> > Because on NTFS there is stored just one field which says when the file
> > was created. There are not two fields like "time set by user and time
> > set by system".
> >
> > Windows security model allows anybody with WRITE_ATTRIBUTES access to
> > change that create time. Linux security model does not allow to change it.
> >
> > NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> > In my opinion if the ext4 or btrfs filesystem is correctly implemented
> > on Windows systems, then Windows security model should handle it in the
> > same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> > access, then Windows should allow to change also btime on ext4 or btrfs.
> >
> >
> >
> > On the other hand, I understand the use case to have two creation times.
> > One time which would never be changed and could be used for any kind of
> > atomic / synchronization by userspace application logic (this btime).
> > And another time for human which can be changed at any time to any value
> > which user wants (this ptime).
> >
> > In any case, I would suggest that filesystem driver would not report to
> > userspace unsupported values and would not try to invent other values
> > and lying about them.
> 
> But all those fs with mutable creation time already report it with STATX_BTIME
> so what can we do about this?

Well, what I wanted above to point out is that the "mutability" of
creation time is not feature of filesystem, but in my opinion rather
property of the security model on the running operating system.

Maybe better question is: how ext4 btimes differs from the ntfs btime?
In my opinion there is no much difference, both of them has meaning
"time when was the file created".

> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
> those fs could technically return only STATX_PTIME and it should not regress
> existing programs.
> 
> But this is still a bit surprising behavior is it not?
> 
> Thanks,
> Amir.

I'm not sure what to do with it.

If we allow to change btime of ntfs then for consistency we should also
allow to change btime of ext4.

Maybe another idea... define new capability which would allow to change
btime (on any filesystem)? This would at least make the consistency.

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Andreas Dilger]

On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
> 
> On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
>> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
>>> 
>>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
>>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
>>>>      if (flags & FS_APPEND_FL)
>>>>              new_fl |= S_APPEND;
>>>> 
>>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
>>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
>>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
>>>> +     }
>>>> +
>>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
>>>> 
>>>>      /* Save nodump flag to return in ntfs_getattr. */
>>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
>>>>      if (unlikely(is_bad_ni(ni)))
>>>>              return -EINVAL;
>>>> 
>>>> -     stat->result_mask |= STATX_BTIME;
>>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
>>>>      stat->btime = ni->i_crtime;
>>>> +     stat->ptime = ni->i_crtime;
>>> 
>>> For me this patch looks dangerous. Somehow I would expect that the
>>> "btime" will never change for existing inode.
>>> 
>>> But because the ptime is mapped to i_crtime and ptime is settable from
>>> userspace, with this patch it is directly possible to change btime.
>>> 
>>> 
>>> 
>>> I was thinking more about it... Is not this just misunderstanding of how
>>> the security model around the times is working on different systems?
>>> Because on NTFS there is stored just one field which says when the file
>>> was created. There are not two fields like "time set by user and time
>>> set by system".
>>> 
>>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
>>> change that create time. Linux security model does not allow to change it.
>>> 
>>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
>>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
>>> on Windows systems, then Windows security model should handle it in the
>>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
>>> access, then Windows should allow to change also btime on ext4 or btrfs.
>>> 
>>> 
>>> 
>>> On the other hand, I understand the use case to have two creation times.
>>> One time which would never be changed and could be used for any kind of
>>> atomic / synchronization by userspace application logic (this btime).
>>> And another time for human which can be changed at any time to any value
>>> which user wants (this ptime).
>>> 
>>> In any case, I would suggest that filesystem driver would not report to
>>> userspace unsupported values and would not try to invent other values
>>> and lying about them.
>> 
>> But all those fs with mutable creation time already report it with STATX_BTIME
>> so what can we do about this?
> 
> Well, what I wanted above to point out is that the "mutability" of
> creation time is not feature of filesystem, but in my opinion rather
> property of the security model on the running operating system.
> 
> Maybe better question is: how ext4 btimes differs from the ntfs btime?
> In my opinion there is no much difference, both of them has meaning
> "time when was the file created".
> 
>> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
>> those fs could technically return only STATX_PTIME and it should not regress
>> existing programs.
>> 
>> But this is still a bit surprising behavior is it not?
>> 
>> Thanks,
>> Amir.
> 
> I'm not sure what to do with it.
> 
> If we allow to change btime of ntfs then for consistency we should also
> allow to change btime of ext4.
> 
> Maybe another idea... define new capability which would allow to change
> btime (on any filesystem)? This would at least make the consistency.

I think the ext4 and xfs maintainers have repeatedly said that btime/crtime
attribute should not be modified by users.  There was a long discussion on
this from Ted as well, and the reality is that "creation" time is not worth
the bits that it is written on, since it is not preserved by any tools, has
a "vague" meaning (is it when the *file* was created, when the *content* was
created, do edits update it, is it preserved across filesystems, archives,
etc.) and adding it into the filesystem is misplaced effort.

Storing it as an xattr has some reasonable chance of being preserved across
tar/cp/filesystems, and doesn't introduce a herculean effort of changing
all of the system calls and on-disk formats for every filesystem.

Cheers, Andreas

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Amir Goldstein]

On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
>
> On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
> >
> > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
> >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
> >>>
> >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> >>>>      if (flags & FS_APPEND_FL)
> >>>>              new_fl |= S_APPEND;
> >>>>
> >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> >>>> +     }
> >>>> +
> >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> >>>>
> >>>>      /* Save nodump flag to return in ntfs_getattr. */
> >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> >>>>      if (unlikely(is_bad_ni(ni)))
> >>>>              return -EINVAL;
> >>>>
> >>>> -     stat->result_mask |= STATX_BTIME;
> >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> >>>>      stat->btime = ni->i_crtime;
> >>>> +     stat->ptime = ni->i_crtime;
> >>>
> >>> For me this patch looks dangerous. Somehow I would expect that the
> >>> "btime" will never change for existing inode.
> >>>
> >>> But because the ptime is mapped to i_crtime and ptime is settable from
> >>> userspace, with this patch it is directly possible to change btime.
> >>>
> >>>
> >>>
> >>> I was thinking more about it... Is not this just misunderstanding of how
> >>> the security model around the times is working on different systems?
> >>> Because on NTFS there is stored just one field which says when the file
> >>> was created. There are not two fields like "time set by user and time
> >>> set by system".
> >>>
> >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
> >>> change that create time. Linux security model does not allow to change it.
> >>>
> >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
> >>> on Windows systems, then Windows security model should handle it in the
> >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> >>> access, then Windows should allow to change also btime on ext4 or btrfs.
> >>>
> >>>
> >>>
> >>> On the other hand, I understand the use case to have two creation times.
> >>> One time which would never be changed and could be used for any kind of
> >>> atomic / synchronization by userspace application logic (this btime).
> >>> And another time for human which can be changed at any time to any value
> >>> which user wants (this ptime).
> >>>
> >>> In any case, I would suggest that filesystem driver would not report to
> >>> userspace unsupported values and would not try to invent other values
> >>> and lying about them.
> >>
> >> But all those fs with mutable creation time already report it with STATX_BTIME
> >> so what can we do about this?
> >
> > Well, what I wanted above to point out is that the "mutability" of
> > creation time is not feature of filesystem, but in my opinion rather
> > property of the security model on the running operating system.
> >
> > Maybe better question is: how ext4 btimes differs from the ntfs btime?
> > In my opinion there is no much difference, both of them has meaning
> > "time when was the file created".
> >
> >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
> >> those fs could technically return only STATX_PTIME and it should not regress
> >> existing programs.
> >>
> >> But this is still a bit surprising behavior is it not?
> >>
> >> Thanks,
> >> Amir.
> >
> > I'm not sure what to do with it.
> >
> > If we allow to change btime of ntfs then for consistency we should also
> > allow to change btime of ext4.
> >
> > Maybe another idea... define new capability which would allow to change
> > btime (on any filesystem)? This would at least make the consistency.

Pali, I think this is a very bad idea.
This has nothing to do with capabilities.
The Windows and MacOS filesystems have allowed setting their
"creation time" forever and for all the other Linux filesystems that had
"birth time" it was immutable, so let's not mix filesystem features
with capabilities.

>
> I think the ext4 and xfs maintainers have repeatedly said that btime/crtime
> attribute should not be modified by users.  There was a long discussion on
> this from Ted as well, and the reality is that "creation" time is not worth
> the bits that it is written on,

This is an opinion of individual people, who did not lay out technical
arguments.
I have concrete technical arguments in favor of first class creation time for
ext4/xfs from my experience with production systems that need it and use xattr
to store it (by smbd), but I am not going to list them here because
this is not a
thread about implementing mutable creation time for ext4/xfs.

> since it is not preserved by any tools, has

Facts check:

# NEWS for rsync 3.2.3 (6 Aug 2020)

## Changes in this version:
...
 - Added [`--crtimes`](rsync.1#opt) (`-N`) option for preserving the file's
   create time (I believe that this is macOS only at the moment).

Incidentally, I have an implementation for --crtimes for cifs [1], but this
is not extendable to support all the filsystems which support settable crtime.

> a "vague" meaning (is it when the *file* was created, when the *content* was
> created, do edits update it, is it preserved across filesystems, archives,
> etc.) and adding it into the filesystem is misplaced effort.

Sorry now you are talking nonsense. Meaning has nothing to do with it.
This is a property of filesystems (plural) which have documented APIs
and documented network protocols - it is what it is.

If you are looking for a meaning, it is the first publication date, whether
it means something to you is irrelevant - what's relevant is that customers
use it and want to preserve it in backups, whatever its meaning is.

>
> Storing it as an xattr has some reasonable chance of being preserved across
> tar/cp/filesystems, and doesn't introduce a herculean effort of changing
> all of the system calls and on-disk formats for every filesystem.
>

As I said I can provide data for why the xattr approach taken by smbd is
limited and inferior, but this is not the place to get into it (there are hints
in the rsync commit message below).

Thanks,
Amir.

[1] https://github.com/amir73il/rsync/commits/cifs-crtimes/

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Pali Rohár]

On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
> On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
> >
> > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
> > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
> > >>>
> > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> > >>>>      if (flags & FS_APPEND_FL)
> > >>>>              new_fl |= S_APPEND;
> > >>>>
> > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> > >>>> +     }
> > >>>> +
> > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> > >>>>
> > >>>>      /* Save nodump flag to return in ntfs_getattr. */
> > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> > >>>>      if (unlikely(is_bad_ni(ni)))
> > >>>>              return -EINVAL;
> > >>>>
> > >>>> -     stat->result_mask |= STATX_BTIME;
> > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> > >>>>      stat->btime = ni->i_crtime;
> > >>>> +     stat->ptime = ni->i_crtime;
> > >>>
> > >>> For me this patch looks dangerous. Somehow I would expect that the
> > >>> "btime" will never change for existing inode.
> > >>>
> > >>> But because the ptime is mapped to i_crtime and ptime is settable from
> > >>> userspace, with this patch it is directly possible to change btime.
> > >>>
> > >>>
> > >>>
> > >>> I was thinking more about it... Is not this just misunderstanding of how
> > >>> the security model around the times is working on different systems?
> > >>> Because on NTFS there is stored just one field which says when the file
> > >>> was created. There are not two fields like "time set by user and time
> > >>> set by system".
> > >>>
> > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
> > >>> change that create time. Linux security model does not allow to change it.
> > >>>
> > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
> > >>> on Windows systems, then Windows security model should handle it in the
> > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
> > >>>
> > >>>
> > >>>
> > >>> On the other hand, I understand the use case to have two creation times.
> > >>> One time which would never be changed and could be used for any kind of
> > >>> atomic / synchronization by userspace application logic (this btime).
> > >>> And another time for human which can be changed at any time to any value
> > >>> which user wants (this ptime).
> > >>>
> > >>> In any case, I would suggest that filesystem driver would not report to
> > >>> userspace unsupported values and would not try to invent other values
> > >>> and lying about them.
> > >>
> > >> But all those fs with mutable creation time already report it with STATX_BTIME
> > >> so what can we do about this?
> > >
> > > Well, what I wanted above to point out is that the "mutability" of
> > > creation time is not feature of filesystem, but in my opinion rather
> > > property of the security model on the running operating system.
> > >
> > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
> > > In my opinion there is no much difference, both of them has meaning
> > > "time when was the file created".
> > >
> > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
> > >> those fs could technically return only STATX_PTIME and it should not regress
> > >> existing programs.
> > >>
> > >> But this is still a bit surprising behavior is it not?
> > >>
> > >> Thanks,
> > >> Amir.
> > >
> > > I'm not sure what to do with it.
> > >
> > > If we allow to change btime of ntfs then for consistency we should also
> > > allow to change btime of ext4.
> > >
> > > Maybe another idea... define new capability which would allow to change
> > > btime (on any filesystem)? This would at least make the consistency.
> 
> Pali, I think this is a very bad idea.

Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.

> This has nothing to do with capabilities.
> The Windows and MacOS filesystems have allowed setting their
> "creation time" forever

FreeBSD for some fs allow it too (see below).

> and for all the other Linux filesystems that had
> "birth time" it was immutable, so let's not mix filesystem features
> with capabilities.

I think that it is important to first define behavior and invariants of
these "btime" and "ptime" kernel properties.

If we want to be consistent then there are two possible options:

1. If we choose that the STATX_BTIME is immutable then no kernel fs
   driver should allow to change.

2. If we choose that the "NTFS create time" is reported via STATX_BTIME
   then STATX_BTIME is not immutable at all.

These two options cannot be chosen together because option 1 would
implie that the modifiable "NTFS create time" cannot be reported over
STATX_BTIME.

We are have currently STATX_BTIME immutable and "NTFS create time"
reported via STATX_BTIME.

If we want to stay _consistent_ across fs drivers then adding API for
changing "NTFS create time" would break one of those two things.

In my opinion we should stay consistent across filesystem drivers and
provide unified behavior of APIs independently of used filesystem.
Otherwise userspace applications would have to write fs specific code
for doing their use cases (and we can stay with fs-specific xattrs, no
need to create unified APIs).

Does it make sense? Or it is still a bad idea to think about it in this way?

> >
> > I think the ext4 and xfs maintainers have repeatedly said that btime/crtime
> > attribute should not be modified by users.  There was a long discussion on
> > this from Ted as well, and the reality is that "creation" time is not worth
> > the bits that it is written on,
> 
> This is an opinion of individual people, who did not lay out technical
> arguments.
> I have concrete technical arguments in favor of first class creation time for
> ext4/xfs from my experience with production systems that need it and use xattr
> to store it (by smbd), but I am not going to list them here because
> this is not a
> thread about implementing mutable creation time for ext4/xfs.
> 
> > since it is not preserved by any tools, has
> 
> Facts check:
> 
> # NEWS for rsync 3.2.3 (6 Aug 2020)
> 
> ## Changes in this version:
> ...
>  - Added [`--crtimes`](rsync.1#opt) (`-N`) option for preserving the file's
>    create time (I believe that this is macOS only at the moment).
> 
> Incidentally, I have an implementation for --crtimes for cifs [1], but this
> is not extendable to support all the filsystems which support settable crtime.

Another two facts check:

FreeBSD has also API for changing "birth (creation) times".
It is documented in utimes(2) manpage:
https://man.freebsd.org/cgi/man.cgi?query=utimes&sektion=2

So I guess that there has to be some tool which is using this API and
therefore these "birth (creation) times" are preserved.


NFS4 has time_create attribute (FATTR4_TIME_CREATE=50) which is
per-fs-object read-write attribute and defined (in RFC8881 5.8.2.40.) as:
  The time of creation of the object. This attribute does not have any
  relation to the traditional UNIX file attribute "ctime" or "change time".
Since NFSv4.1 it can be even specified during creating a new file/dir
which seems to be for backup-restore. And permissions (RFC8881 6.2.1.3.1.):
  ACE4_WRITE_ATTRIBUTES
  Operation(s) affected: SETATTR of time_access_set, time_backup,
    time_create, time_modify_set, mimetype, hidden, system
  Discussion: Permission to change the times associated with a file or
    directory to an arbitrary value. Also permission to change the
    mimetype, hidden, and system attributes. A user having ACE4_WRITE_DATA
    or ACE4_WRITE_ATTRIBUTES will be allowed to set the times associated
    with a file to the current server time.

I'm not sure if there is some backup/restore tool which do it over NFS4
but the NFS4 description seems to be very clear that the network protocol
itself is already prepared for these use cases. And permissions mostly
matches the SMB / NTFS / Windows security model.

> > a "vague" meaning (is it when the *file* was created, when the *content* was
> > created, do edits update it, is it preserved across filesystems, archives,
> > etc.) and adding it into the filesystem is misplaced effort.
> 
> Sorry now you are talking nonsense. Meaning has nothing to do with it.
> This is a property of filesystems (plural) which have documented APIs
> and documented network protocols - it is what it is.
> 
> If you are looking for a meaning, it is the first publication date, whether
> it means something to you is irrelevant - what's relevant is that customers
> use it and want to preserve it in backups, whatever its meaning is.

I agree here. I also heard lot of times that users (customers) want to
preserve create time in backups and be able to restore it. And that
Windows is already able to do it, Linux not yet.

Maybe what is a "vague" here is where that "create time" is stored and
from which (API) source is GUI (or CLI) application showing it to user.

> >
> > Storing it as an xattr has some reasonable chance of being preserved across
> > tar/cp/filesystems, and doesn't introduce a herculean effort of changing
> > all of the system calls and on-disk formats for every filesystem.
> >

I think the part "being preserved across tar/cp/filesystems" is
relevant. If a completely new API is introduced into Linux then it means
that every existing backup tool would not be able to preserve this
property and also would not be able to restore it.

I'm not sure if we can do anything with this issue, but it is important
to know about this limitation.

About the part "introduce a herculean effort of changing all of the
system calls and on-disk formats for every filesystem.". In my opinion
it is better to do that cleanup (maybe even in all stat-related
syscalls) if it makes things easier and prevents another technical
issues.

> 
> As I said I can provide data for why the xattr approach taken by smbd is
> limited and inferior, but this is not the place to get into it (there are hints
> in the rsync commit message below).
> 
> Thanks,
> Amir.
> 
> [1] https://github.com/amir73il/rsync/commits/cifs-crtimes/

I would say that xattr does not solve this issue too.

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 13492 bytes --]

Hi and sorry for the late reply,

On Tue Nov 3, 2026 at 10:49 AM CET, Pali Rohár wrote:
> On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
>> On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
>> >
>> > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
>> > >
>> > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
>> > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
>> > >>>
>> > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
>> > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
>> > >>>>      if (flags & FS_APPEND_FL)
>> > >>>>              new_fl |= S_APPEND;
>> > >>>>
>> > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
>> > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
>> > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
>> > >>>> +     }
>> > >>>> +
>> > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
>> > >>>>
>> > >>>>      /* Save nodump flag to return in ntfs_getattr. */
>> > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
>> > >>>>      if (unlikely(is_bad_ni(ni)))
>> > >>>>              return -EINVAL;
>> > >>>>
>> > >>>> -     stat->result_mask |= STATX_BTIME;
>> > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
>> > >>>>      stat->btime = ni->i_crtime;
>> > >>>> +     stat->ptime = ni->i_crtime;
>> > >>>
>> > >>> For me this patch looks dangerous. Somehow I would expect that the
>> > >>> "btime" will never change for existing inode.
>> > >>>
>> > >>> But because the ptime is mapped to i_crtime and ptime is settable from
>> > >>> userspace, with this patch it is directly possible to change btime.
>> > >>>
>> > >>>
>> > >>>
>> > >>> I was thinking more about it... Is not this just misunderstanding of how
>> > >>> the security model around the times is working on different systems?
>> > >>> Because on NTFS there is stored just one field which says when the file
>> > >>> was created. There are not two fields like "time set by user and time
>> > >>> set by system".
>> > >>>
>> > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
>> > >>> change that create time. Linux security model does not allow to change it.
>> > >>>
>> > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
>> > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
>> > >>> on Windows systems, then Windows security model should handle it in the
>> > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
>> > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
>> > >>>
>> > >>>
>> > >>>
>> > >>> On the other hand, I understand the use case to have two creation times.
>> > >>> One time which would never be changed and could be used for any kind of
>> > >>> atomic / synchronization by userspace application logic (this btime).
>> > >>> And another time for human which can be changed at any time to any value
>> > >>> which user wants (this ptime).
>> > >>>
>> > >>> In any case, I would suggest that filesystem driver would not report to
>> > >>> userspace unsupported values and would not try to invent other values
>> > >>> and lying about them.
>> > >>
>> > >> But all those fs with mutable creation time already report it with STATX_BTIME
>> > >> so what can we do about this?
>> > >
>> > > Well, what I wanted above to point out is that the "mutability" of
>> > > creation time is not feature of filesystem, but in my opinion rather
>> > > property of the security model on the running operating system.
>> > >
>> > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
>> > > In my opinion there is no much difference, both of them has meaning
>> > > "time when was the file created".
>> > >
>> > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
>> > >> those fs could technically return only STATX_PTIME and it should not regress
>> > >> existing programs.
>> > >>
>> > >> But this is still a bit surprising behavior is it not?
>> > >>
>> > >> Thanks,
>> > >> Amir.
>> > >
>> > > I'm not sure what to do with it.
>> > >
>> > > If we allow to change btime of ntfs then for consistency we should also
>> > > allow to change btime of ext4.
>> > >
>> > > Maybe another idea... define new capability which would allow to change
>> > > btime (on any filesystem)? This would at least make the consistency.
>> 
>> Pali, I think this is a very bad idea.
>
> Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
>
>> This has nothing to do with capabilities.
>> The Windows and MacOS filesystems have allowed setting their
>> "creation time" forever
>
> FreeBSD for some fs allow it too (see below).
>
>> and for all the other Linux filesystems that had
>> "birth time" it was immutable, so let's not mix filesystem features
>> with capabilities.
>
> I think that it is important to first define behavior and invariants of
> these "btime" and "ptime" kernel properties.
>
> If we want to be consistent then there are two possible options:
>
> 1. If we choose that the STATX_BTIME is immutable then no kernel fs
>    driver should allow to change.
>
> 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
>    then STATX_BTIME is not immutable at all.
>
> These two options cannot be chosen together because option 1 would
> implie that the modifiable "NTFS create time" cannot be reported over
> STATX_BTIME.
>
> We are have currently STATX_BTIME immutable and "NTFS create time"
> reported via STATX_BTIME.
>
> If we want to stay _consistent_ across fs drivers then adding API for
> changing "NTFS create time" would break one of those two things.
>
> In my opinion we should stay consistent across filesystem drivers and
> provide unified behavior of APIs independently of used filesystem.
> Otherwise userspace applications would have to write fs specific code
> for doing their use cases (and we can stay with fs-specific xattrs, no
> need to create unified APIs).
>
> Does it make sense? Or it is still a bad idea to think about it in this way?

Personally I think in this discussion we should separate linux
filesystems vs non-linux filesystems, as linux filesystems are "ours"
and are the ones we can change as we want, while non-linux filesystems
are not made by "us" and cannot be easily changed (like NFS I would say)
or cannot changed at all (e.g. NTFS (well, unless we make ntfs
incompatible with windows lol)).

But I understand why it would be better to keep a unified API across all
filesystems, even "non-official" ones, so I can think of 2 options
(well, with ntfs/exfat in mind, as I don't know much about NFS/smb):

1) keep btime aliased to ptime, which means that (to userspace) btime
   would be mutable for ntfs/exfat/vfat/etc

2) move ntfs/exfat/vfat/etc's cr_time from btime to ptime, effectively
   "removing" btime from those FSs and "keeping" only ptime; in this case
   stat would show "-" for Birth:, but would show the correct timestamp for
   Origin:/Create:/Provenance:/...

I prefer 1) because it probably breaks less scripts, but 2) would be
more correct semantically.

And both break at least 1 existing script anyway (as per https://xkcd.com/1172/).

>> >
>> > I think the ext4 and xfs maintainers have repeatedly said that btime/crtime
>> > attribute should not be modified by users.  There was a long discussion on
>> > this from Ted as well, and the reality is that "creation" time is not worth
>> > the bits that it is written on,
>> 
>> This is an opinion of individual people, who did not lay out technical
>> arguments.
>> I have concrete technical arguments in favor of first class creation time for
>> ext4/xfs from my experience with production systems that need it and use xattr
>> to store it (by smbd), but I am not going to list them here because
>> this is not a
>> thread about implementing mutable creation time for ext4/xfs.

For my (backups, preservation) use case, making btime mutable would also
be fine, but I can see the value of having a "ctime" for creation, hence
this RFC.

>> 
>> > since it is not preserved by any tools, has
>> 
>> Facts check:
>> 
>> # NEWS for rsync 3.2.3 (6 Aug 2020)
>> 
>> ## Changes in this version:
>> ...
>>  - Added [`--crtimes`](rsync.1#opt) (`-N`) option for preserving the file's
>>    create time (I believe that this is macOS only at the moment).
>> 
>> Incidentally, I have an implementation for --crtimes for cifs [1], but this
>> is not extendable to support all the filsystems which support settable crtime.
>
> Another two facts check:
>
> FreeBSD has also API for changing "birth (creation) times".
> It is documented in utimes(2) manpage:
> https://man.freebsd.org/cgi/man.cgi?query=utimes&sektion=2
>
> So I guess that there has to be some tool which is using this API and
> therefore these "birth (creation) times" are preserved.
>
>
> NFS4 has time_create attribute (FATTR4_TIME_CREATE=50) which is
> per-fs-object read-write attribute and defined (in RFC8881 5.8.2.40.) as:
>   The time of creation of the object. This attribute does not have any
>   relation to the traditional UNIX file attribute "ctime" or "change time".
> Since NFSv4.1 it can be even specified during creating a new file/dir
> which seems to be for backup-restore. And permissions (RFC8881 6.2.1.3.1.):
>   ACE4_WRITE_ATTRIBUTES
>   Operation(s) affected: SETATTR of time_access_set, time_backup,
>     time_create, time_modify_set, mimetype, hidden, system
>   Discussion: Permission to change the times associated with a file or
>     directory to an arbitrary value. Also permission to change the
>     mimetype, hidden, and system attributes. A user having ACE4_WRITE_DATA
>     or ACE4_WRITE_ATTRIBUTES will be allowed to set the times associated
>     with a file to the current server time.
>
> I'm not sure if there is some backup/restore tool which do it over NFS4
> but the NFS4 description seems to be very clear that the network protocol
> itself is already prepared for these use cases. And permissions mostly
> matches the SMB / NTFS / Windows security model.
>
>> > a "vague" meaning (is it when the *file* was created, when the *content* was
>> > created, do edits update it, is it preserved across filesystems, archives,
>> > etc.) and adding it into the filesystem is misplaced effort.
>> 
>> Sorry now you are talking nonsense. Meaning has nothing to do with it.
>> This is a property of filesystems (plural) which have documented APIs
>> and documented network protocols - it is what it is.
>> 
>> If you are looking for a meaning, it is the first publication date, whether
>> it means something to you is irrelevant - what's relevant is that customers
>> use it and want to preserve it in backups, whatever its meaning is.
>
> I agree here. I also heard lot of times that users (customers) want to
> preserve create time in backups and be able to restore it. And that
> Windows is already able to do it, Linux not yet.

Hi I'm one of those users, I still can't believe no-one has implemented
something like this yet since POSIX came out way back when (*cry*).

> Maybe what is a "vague" here is where that "create time" is stored and
> from which (API) source is GUI (or CLI) application showing it to user.
>
>> >
>> > Storing it as an xattr has some reasonable chance of being preserved across
>> > tar/cp/filesystems, and doesn't introduce a herculean effort of changing
>> > all of the system calls and on-disk formats for every filesystem.
>> >
>
> I think the part "being preserved across tar/cp/filesystems" is
> relevant. If a completely new API is introduced into Linux then it means
> that every existing backup tool would not be able to preserve this
> property and also would not be able to restore it.
>
> I'm not sure if we can do anything with this issue, but it is important
> to know about this limitation.

My thinking for this RFC would be to then submit relevant patches also
to at least the main tools I use like tar, cp, rsync and vim, which will
hopefully make it gain momentum and be supported also in other less
well-known tools (I would also love for it to be supported by HTTP like
mtime is, but that will likely be a lot more difficult to get accepted
and implemented).

> About the part "introduce a herculean effort of changing all of the
> system calls and on-disk formats for every filesystem.". In my opinion
> it is better to do that cleanup (maybe even in all stat-related
> syscalls) if it makes things easier and prevents another technical
> issues.
>
>> 
>> As I said I can provide data for why the xattr approach taken by smbd is
>> limited and inferior, but this is not the place to get into it (there are hints
>> in the rsync commit message below).
>> 
>> Thanks,
>> Amir.
>> 
>> [1] https://github.com/amir73il/rsync/commits/cifs-crtimes/
>
> I would say that xattr does not solve this issue too.

I would also like to note again that xattrs aren't available to symlinks
(or other special files), which would break at least my backup/preservation
use case.

Best,
koraynilay

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH v3 1/5] vfs: add provenance time (ptime)

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 3945 bytes --]

On Mon Nov 2, 2026 at 3:00 PM CET, Amir Goldstein wrote:
> On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> wrote:
>>
>> Add provenance time (ptime), indicating the time when a file or
>> directory was created. This is user-settable via file_setattr() and
>> retrievable via statx(2) (using STATX_PTIME) or file_getattr().
>>
>> The semantics of when to preserve this new timestamp are the same as
>> mtime, the idea being that there is a correspondence like this:
>>
>> ctime <-> btime
>> mtime <-> ptime
>>
>> so every operation (copying, moving, ...) that currently preserves mtime
>> should also preserve ptime.
>>
>> Furthermore, in order to avoid the legacy FS_IOC_FSSETXATTR accepting
>> FS_XFLAG_PTIME, add an FS_FILE_ATTR_XFLAGS_MASK mask to support new
>> xflags, and use it in fileattr_to_file_attr()/file_attr_to_fileattr() to
>> allow ptime to be used with the file_setattr()/file_getattr() syscalls.
>>
>> [ This is a re-implementation of the initial patch[1] by Sean Smith
>>   <defendthedisabled@gmail.com>, following the advice[2] from Darrick J.
>>   Wong <djwong@kernel.org> of using file_setattr() instead of updating
>>   utimensat() ]
>>
>> [1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@gmail.com
>> [2]: https://lore.kernel.org/20260407014129.GC6192@frogsfrogsfrogs
>>
>> Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
>> Signed-off-by: koraynilay <koray.fra@gmail.com>
>> ---
>>  fs/file_attr.c            | 33 +++++++++++++++++++++++++++++++--
>>  fs/stat.c                 |  2 ++
>>  include/linux/fileattr.h  |  5 +++++
>>  include/linux/stat.h      |  1 +
>>  include/uapi/linux/fs.h   |  8 +++++++-
>>  include/uapi/linux/stat.h |  7 ++++++-
>>  6 files changed, 52 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/file_attr.c b/fs/file_attr.c
>> index 833e03810b24..c0645cb22bf3 100644
>> --- a/fs/file_attr.c
>> +++ b/fs/file_attr.c
>> @@ -102,7 +102,7 @@ EXPORT_SYMBOL(vfs_fileattr_get);
>>  static void fileattr_to_file_attr(const struct file_kattr *fa,
>>                                   struct file_attr *fattr)
>>  {
>> -       __u32 mask = FS_XFLAGS_MASK;
>> +       __u32 mask = FS_FILE_ATTR_XFLAGS_MASK;
>>
>>         memset(fattr, 0, sizeof(struct file_attr));
>>         fattr->fa_xflags = fa->fsx_xflags & mask;
>> @@ -110,6 +110,8 @@ static void fileattr_to_file_attr(const struct file_kattr *fa,
>>         fattr->fa_nextents = fa->fsx_nextents;
>>         fattr->fa_projid = fa->fsx_projid;
>>         fattr->fa_cowextsize = fa->fsx_cowextsize;
>> +       fattr->fa_ptime_sec = fa->fsx_ptime.tv_sec;
>> +       fattr->fa_ptime_nsec = fa->fsx_ptime.tv_nsec;
>>  }
>>
>>  /**
>> @@ -141,15 +143,20 @@ EXPORT_SYMBOL(copy_fsxattr_to_user);
>>  static int file_attr_to_fileattr(const struct file_attr *fattr,
>>                                  struct file_kattr *fa)
>>  {
>> -       __u64 mask = FS_XFLAGS_MASK;
>> +       __u64 mask = FS_FILE_ATTR_XFLAGS_MASK;
>
> That is not the correct way to extend this API.
> This fixed mask was added as a placeholder for
> "We intend to add support for more xflags to selective filesystems":
> https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-2-amir73il@gmail.com/
>
> Please see this POC patch for filesystems to publish their supported
> xflags mask:
> https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-3-amir73il@gmail.com/

Thanks, I did not think of adding a dynamic mask like that, I will look
into it and implement it for v4.

> This will allow callers of file_getattr() to know if the filesystem
> supports ptime
> without trying to set it and failing.

So after adding fsx_xflags_mask to file_kattr, every filesystem would
populate fsx_xflags_mask with all the returned (== supported) FS_XFLAG_*
in their own specific .fileattr_get, correct?

Best,
koraynilay

> Thanks,
> Amir.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH v3 0/5] add provenance time (ptime)

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 6137 bytes --]

On Mon Nov 2, 2026 at 3:54 PM CET, Amir Goldstein wrote:
> On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> wrote:
>>
>> 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.
>
> FWIW, I agree that given the existing uses of btime and crtime in the
> kernel and various XXXprogs, using 'ptime' for kernel code is probably
> the lesser evil.

What do you think about the origiN time (ntime) (Origin: in stat)?
It would also coincidentally be alphabetically (ntime <-> mtime, n -> m)
the same as btime <-> ctime (b -> c) ahah.

> The question of how to display this in stat and tool is a different question
> that can be left to the userspace developers.
>
> The UAPI headers uses Birth time language and stat displays:
>
> Access: 2026-11-02 15:22:27.067329367 +0100
> Modify: 2026-11-02 15:22:27.067329367 +0100
> Change: 2026-11-02 15:22:27.067329367 +0100
>  Birth: 2026-11-02 15:22:27.067329367 +0100
>
> If the UAPI headers will use consistent language:
>
> +       /* provenance (settable creation) time */
>
> +       __s64 fa_ptime_sec;     /* provenance (settable creation) time
> (seconds) */
>
> I  think that the man pages could be unambiguous:
>
> stat(1)
>        %w     time of file birth (immutable), human-readable; - if unknown
>        %W    time of file birth (immutable), seconds since Epoch; 0 if unknown
>        %p     time of file creation (mutable), human-readable; - if unknown
>        %P     time of file creation (mutable), seconds since Epoch; 0 if unknown
>
> statx(2)
>        stx_btime
>               The file's (immutable) creation timestamp.
>        stx_ptime
>               The file's (mutable) creation timestamp.
>
> And userspace tools could be displaying ptime as:
>
> Access: 2026-11-02 15:22:27.067329367 +0100
> Modify: 2026-11-02 15:22:27.067329367 +0100
> Change: 2026-11-02 15:22:27.067329367 +0100
> Create: 2026-11-02 15:22:27.067329367 +0100
>  Birth: 2026-11-02 15:22:27.067329367 +0100
>
> If they want to, without that being more confusing than Provenance.

That's fair, I don't like too much the fact that this would have a
different name vs the variable name (as all other timestamps do), but it
would be fine IMO.

>>
>> 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])
>
> Please see my review on patch 1/5 on exporting the supported mask
> to userspace.
>
>> - 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
>
> Please explain what makes them more complex.
> My concern is that I would like to see that the proposed API fits the existing
> fs and we won't need to change the API again later to support them.

By "more complex" I mean just that when grepping the code I noticed ntfs
and exfat were very straightforward to implement, while vfat had the
msdos/non-msdos handling and smb had a completely different structure,
so I thought it would be fine to have ntfs/exfat as proof-of-concepts at
first.

For v4 I can check and see how easy/difficult to implement ptime in smb
and nfs (and vfat) is if you prefer, or keep that for v5 and v4 for the
mask change.

Thanks,
koraynilay

> Thanks,
> Amir.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Pali Rohár]

On Tuesday 03 November 2026 12:04:39 koraynilay wrote:
> Hi and sorry for the late reply,
> 
> On Tue Nov 3, 2026 at 10:49 AM CET, Pali Rohár wrote:
> > On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
> >> On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
> >> >
> >> > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
> >> > >
> >> > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
> >> > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
> >> > >>>
> >> > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> >> > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> >> > >>>>      if (flags & FS_APPEND_FL)
> >> > >>>>              new_fl |= S_APPEND;
> >> > >>>>
> >> > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> >> > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> >> > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> >> > >>>> +     }
> >> > >>>> +
> >> > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> >> > >>>>
> >> > >>>>      /* Save nodump flag to return in ntfs_getattr. */
> >> > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> >> > >>>>      if (unlikely(is_bad_ni(ni)))
> >> > >>>>              return -EINVAL;
> >> > >>>>
> >> > >>>> -     stat->result_mask |= STATX_BTIME;
> >> > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> >> > >>>>      stat->btime = ni->i_crtime;
> >> > >>>> +     stat->ptime = ni->i_crtime;
> >> > >>>
> >> > >>> For me this patch looks dangerous. Somehow I would expect that the
> >> > >>> "btime" will never change for existing inode.
> >> > >>>
> >> > >>> But because the ptime is mapped to i_crtime and ptime is settable from
> >> > >>> userspace, with this patch it is directly possible to change btime.
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> I was thinking more about it... Is not this just misunderstanding of how
> >> > >>> the security model around the times is working on different systems?
> >> > >>> Because on NTFS there is stored just one field which says when the file
> >> > >>> was created. There are not two fields like "time set by user and time
> >> > >>> set by system".
> >> > >>>
> >> > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
> >> > >>> change that create time. Linux security model does not allow to change it.
> >> > >>>
> >> > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> >> > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
> >> > >>> on Windows systems, then Windows security model should handle it in the
> >> > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> >> > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> On the other hand, I understand the use case to have two creation times.
> >> > >>> One time which would never be changed and could be used for any kind of
> >> > >>> atomic / synchronization by userspace application logic (this btime).
> >> > >>> And another time for human which can be changed at any time to any value
> >> > >>> which user wants (this ptime).
> >> > >>>
> >> > >>> In any case, I would suggest that filesystem driver would not report to
> >> > >>> userspace unsupported values and would not try to invent other values
> >> > >>> and lying about them.
> >> > >>
> >> > >> But all those fs with mutable creation time already report it with STATX_BTIME
> >> > >> so what can we do about this?
> >> > >
> >> > > Well, what I wanted above to point out is that the "mutability" of
> >> > > creation time is not feature of filesystem, but in my opinion rather
> >> > > property of the security model on the running operating system.
> >> > >
> >> > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
> >> > > In my opinion there is no much difference, both of them has meaning
> >> > > "time when was the file created".
> >> > >
> >> > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
> >> > >> those fs could technically return only STATX_PTIME and it should not regress
> >> > >> existing programs.
> >> > >>
> >> > >> But this is still a bit surprising behavior is it not?
> >> > >>
> >> > >> Thanks,
> >> > >> Amir.
> >> > >
> >> > > I'm not sure what to do with it.
> >> > >
> >> > > If we allow to change btime of ntfs then for consistency we should also
> >> > > allow to change btime of ext4.
> >> > >
> >> > > Maybe another idea... define new capability which would allow to change
> >> > > btime (on any filesystem)? This would at least make the consistency.
> >> 
> >> Pali, I think this is a very bad idea.
> >
> > Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
> >
> >> This has nothing to do with capabilities.
> >> The Windows and MacOS filesystems have allowed setting their
> >> "creation time" forever
> >
> > FreeBSD for some fs allow it too (see below).
> >
> >> and for all the other Linux filesystems that had
> >> "birth time" it was immutable, so let's not mix filesystem features
> >> with capabilities.
> >
> > I think that it is important to first define behavior and invariants of
> > these "btime" and "ptime" kernel properties.
> >
> > If we want to be consistent then there are two possible options:
> >
> > 1. If we choose that the STATX_BTIME is immutable then no kernel fs
> >    driver should allow to change.
> >
> > 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
> >    then STATX_BTIME is not immutable at all.
> >
> > These two options cannot be chosen together because option 1 would
> > implie that the modifiable "NTFS create time" cannot be reported over
> > STATX_BTIME.
> >
> > We are have currently STATX_BTIME immutable and "NTFS create time"
> > reported via STATX_BTIME.
> >
> > If we want to stay _consistent_ across fs drivers then adding API for
> > changing "NTFS create time" would break one of those two things.
> >
> > In my opinion we should stay consistent across filesystem drivers and
> > provide unified behavior of APIs independently of used filesystem.
> > Otherwise userspace applications would have to write fs specific code
> > for doing their use cases (and we can stay with fs-specific xattrs, no
> > need to create unified APIs).
> >
> > Does it make sense? Or it is still a bad idea to think about it in this way?
> 
> Personally I think in this discussion we should separate linux
> filesystems vs non-linux filesystems, as linux filesystems are "ours"
> and are the ones we can change as we want, while non-linux filesystems
> are not made by "us" and cannot be easily changed (like NFS I would say)
> or cannot changed at all (e.g. NTFS (well, unless we make ntfs
> incompatible with windows lol)).
> 
> But I understand why it would be better to keep a unified API across all
> filesystems, even "non-official" ones, so I can think of 2 options
> (well, with ntfs/exfat in mind, as I don't know much about NFS/smb):

SMB for timestamps has exactly same meaning and storage format as NTFS.
So it should be pretty straightforward what to do with it.
NFS3 does not have btime at all. And NFS4 has FATTR4_TIME_CREATE attr
which I described in previous email (there is no more info). So based on
the decision of 1 or 2, that NFS4 attr would either map to btime or ptime.

> 
> 1) keep btime aliased to ptime, which means that (to userspace) btime
>    would be mutable for ntfs/exfat/vfat/etc
> 
> 2) move ntfs/exfat/vfat/etc's cr_time from btime to ptime, effectively
>    "removing" btime from those FSs and "keeping" only ptime; in this case
>    stat would show "-" for Birth:, but would show the correct timestamp for
>    Origin:/Create:/Provenance:/...
> 
> I prefer 1) because it probably breaks less scripts, but 2) would be
> more correct semantically.

My personal opinion is 2) because the btime stay immutable also in
userspace and is also more correct semantically.

Another argument why 2) should be less breaking change: Userspace
applications have to already expect that the btime is not filled at all
(e.g. when filesystem does not support it or when application is running
on older kernel version without such support).

My opinion is that if the _new_ API provides two different timestamps
based on the filesystem then we should report it as is, so userspace can
decide how to want to process them. For example full 1:1 clone backup
application would want to preserve both btime and ptime and correctly
indicate if one of them is not available (e.g. because underlying fs
support only one of those times, like NTFS). And such full 1:1 clone
backup application do not want to "invent" some unavailable values.
Option 1) would not allow to do that for such applications.

> And both break at least 1 existing script anyway (as per https://xkcd.com/1172/).

Yes. And that is because we want a new feature which allows changing
something which was immutable. So we need to handle it somehow.

> >> >
> >> > I think the ext4 and xfs maintainers have repeatedly said that btime/crtime
> >> > attribute should not be modified by users.  There was a long discussion on
> >> > this from Ted as well, and the reality is that "creation" time is not worth
> >> > the bits that it is written on,
> >> 
> >> This is an opinion of individual people, who did not lay out technical
> >> arguments.
> >> I have concrete technical arguments in favor of first class creation time for
> >> ext4/xfs from my experience with production systems that need it and use xattr
> >> to store it (by smbd), but I am not going to list them here because
> >> this is not a
> >> thread about implementing mutable creation time for ext4/xfs.
> 
> For my (backups, preservation) use case, making btime mutable would also
> be fine, but I can see the value of having a "ctime" for creation, hence
> this RFC.
> 
> >> 
> >> > since it is not preserved by any tools, has
> >> 
> >> Facts check:
> >> 
> >> # NEWS for rsync 3.2.3 (6 Aug 2020)
> >> 
> >> ## Changes in this version:
> >> ...
> >>  - Added [`--crtimes`](rsync.1#opt) (`-N`) option for preserving the file's
> >>    create time (I believe that this is macOS only at the moment).
> >> 
> >> Incidentally, I have an implementation for --crtimes for cifs [1], but this
> >> is not extendable to support all the filsystems which support settable crtime.
> >
> > Another two facts check:
> >
> > FreeBSD has also API for changing "birth (creation) times".
> > It is documented in utimes(2) manpage:
> > https://man.freebsd.org/cgi/man.cgi?query=utimes&sektion=2
> >
> > So I guess that there has to be some tool which is using this API and
> > therefore these "birth (creation) times" are preserved.
> >
> >
> > NFS4 has time_create attribute (FATTR4_TIME_CREATE=50) which is
> > per-fs-object read-write attribute and defined (in RFC8881 5.8.2.40.) as:
> >   The time of creation of the object. This attribute does not have any
> >   relation to the traditional UNIX file attribute "ctime" or "change time".
> > Since NFSv4.1 it can be even specified during creating a new file/dir
> > which seems to be for backup-restore. And permissions (RFC8881 6.2.1.3.1.):
> >   ACE4_WRITE_ATTRIBUTES
> >   Operation(s) affected: SETATTR of time_access_set, time_backup,
> >     time_create, time_modify_set, mimetype, hidden, system
> >   Discussion: Permission to change the times associated with a file or
> >     directory to an arbitrary value. Also permission to change the
> >     mimetype, hidden, and system attributes. A user having ACE4_WRITE_DATA
> >     or ACE4_WRITE_ATTRIBUTES will be allowed to set the times associated
> >     with a file to the current server time.
> >
> > I'm not sure if there is some backup/restore tool which do it over NFS4
> > but the NFS4 description seems to be very clear that the network protocol
> > itself is already prepared for these use cases. And permissions mostly
> > matches the SMB / NTFS / Windows security model.
> >
> >> > a "vague" meaning (is it when the *file* was created, when the *content* was
> >> > created, do edits update it, is it preserved across filesystems, archives,
> >> > etc.) and adding it into the filesystem is misplaced effort.
> >> 
> >> Sorry now you are talking nonsense. Meaning has nothing to do with it.
> >> This is a property of filesystems (plural) which have documented APIs
> >> and documented network protocols - it is what it is.
> >> 
> >> If you are looking for a meaning, it is the first publication date, whether
> >> it means something to you is irrelevant - what's relevant is that customers
> >> use it and want to preserve it in backups, whatever its meaning is.
> >
> > I agree here. I also heard lot of times that users (customers) want to
> > preserve create time in backups and be able to restore it. And that
> > Windows is already able to do it, Linux not yet.
> 
> Hi I'm one of those users, I still can't believe no-one has implemented
> something like this yet since POSIX came out way back when (*cry*).
> 
> > Maybe what is a "vague" here is where that "create time" is stored and
> > from which (API) source is GUI (or CLI) application showing it to user.
> >
> >> >
> >> > Storing it as an xattr has some reasonable chance of being preserved across
> >> > tar/cp/filesystems, and doesn't introduce a herculean effort of changing
> >> > all of the system calls and on-disk formats for every filesystem.
> >> >
> >
> > I think the part "being preserved across tar/cp/filesystems" is
> > relevant. If a completely new API is introduced into Linux then it means
> > that every existing backup tool would not be able to preserve this
> > property and also would not be able to restore it.
> >
> > I'm not sure if we can do anything with this issue, but it is important
> > to know about this limitation.
> 
> My thinking for this RFC would be to then submit relevant patches also
> to at least the main tools I use like tar, cp, rsync and vim, which will
> hopefully make it gain momentum and be supported also in other less
> well-known tools (I would also love for it to be supported by HTTP like
> mtime is, but that will likely be a lot more difficult to get accepted
> and implemented).

If having two btime and ptime fields would be the direction then we can
propose an extension for NFS4 protocol with a new attribute (as NFS4 has
currently only one). There are already some NFS4 extensions which comes
from Linux or was inspired, e.g. umask or xattr support.

> > About the part "introduce a herculean effort of changing all of the
> > system calls and on-disk formats for every filesystem.". In my opinion
> > it is better to do that cleanup (maybe even in all stat-related
> > syscalls) if it makes things easier and prevents another technical
> > issues.
> >
> >> 
> >> As I said I can provide data for why the xattr approach taken by smbd is
> >> limited and inferior, but this is not the place to get into it (there are hints
> >> in the rsync commit message below).
> >> 
> >> Thanks,
> >> Amir.
> >> 
> >> [1] https://github.com/amir73il/rsync/commits/cifs-crtimes/
> >
> > I would say that xattr does not solve this issue too.
> 
> I would also like to note again that xattrs aren't available to symlinks
> (or other special files), which would break at least my backup/preservation
> use case.
> 
> Best,
> koraynilay

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 16586 bytes --]

On Tue Nov 3, 2026 at 12:38 PM CET, Pali Rohár wrote:
> On Tuesday 03 November 2026 12:04:39 koraynilay wrote:
>> Hi and sorry for the late reply,
>> 
>> On Tue Nov 3, 2026 at 10:49 AM CET, Pali Rohár wrote:
>> > On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
>> >> On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
>> >> >
>> >> > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
>> >> > >
>> >> > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
>> >> > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
>> >> > >>>
>> >> > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
>> >> > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
>> >> > >>>>      if (flags & FS_APPEND_FL)
>> >> > >>>>              new_fl |= S_APPEND;
>> >> > >>>>
>> >> > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
>> >> > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
>> >> > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
>> >> > >>>> +     }
>> >> > >>>> +
>> >> > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
>> >> > >>>>
>> >> > >>>>      /* Save nodump flag to return in ntfs_getattr. */
>> >> > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
>> >> > >>>>      if (unlikely(is_bad_ni(ni)))
>> >> > >>>>              return -EINVAL;
>> >> > >>>>
>> >> > >>>> -     stat->result_mask |= STATX_BTIME;
>> >> > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
>> >> > >>>>      stat->btime = ni->i_crtime;
>> >> > >>>> +     stat->ptime = ni->i_crtime;
>> >> > >>>
>> >> > >>> For me this patch looks dangerous. Somehow I would expect that the
>> >> > >>> "btime" will never change for existing inode.
>> >> > >>>
>> >> > >>> But because the ptime is mapped to i_crtime and ptime is settable from
>> >> > >>> userspace, with this patch it is directly possible to change btime.
>> >> > >>>
>> >> > >>>
>> >> > >>>
>> >> > >>> I was thinking more about it... Is not this just misunderstanding of how
>> >> > >>> the security model around the times is working on different systems?
>> >> > >>> Because on NTFS there is stored just one field which says when the file
>> >> > >>> was created. There are not two fields like "time set by user and time
>> >> > >>> set by system".
>> >> > >>>
>> >> > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
>> >> > >>> change that create time. Linux security model does not allow to change it.
>> >> > >>>
>> >> > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
>> >> > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
>> >> > >>> on Windows systems, then Windows security model should handle it in the
>> >> > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
>> >> > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
>> >> > >>>
>> >> > >>>
>> >> > >>>
>> >> > >>> On the other hand, I understand the use case to have two creation times.
>> >> > >>> One time which would never be changed and could be used for any kind of
>> >> > >>> atomic / synchronization by userspace application logic (this btime).
>> >> > >>> And another time for human which can be changed at any time to any value
>> >> > >>> which user wants (this ptime).
>> >> > >>>
>> >> > >>> In any case, I would suggest that filesystem driver would not report to
>> >> > >>> userspace unsupported values and would not try to invent other values
>> >> > >>> and lying about them.
>> >> > >>
>> >> > >> But all those fs with mutable creation time already report it with STATX_BTIME
>> >> > >> so what can we do about this?
>> >> > >
>> >> > > Well, what I wanted above to point out is that the "mutability" of
>> >> > > creation time is not feature of filesystem, but in my opinion rather
>> >> > > property of the security model on the running operating system.
>> >> > >
>> >> > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
>> >> > > In my opinion there is no much difference, both of them has meaning
>> >> > > "time when was the file created".
>> >> > >
>> >> > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
>> >> > >> those fs could technically return only STATX_PTIME and it should not regress
>> >> > >> existing programs.
>> >> > >>
>> >> > >> But this is still a bit surprising behavior is it not?
>> >> > >>
>> >> > >> Thanks,
>> >> > >> Amir.
>> >> > >
>> >> > > I'm not sure what to do with it.
>> >> > >
>> >> > > If we allow to change btime of ntfs then for consistency we should also
>> >> > > allow to change btime of ext4.
>> >> > >
>> >> > > Maybe another idea... define new capability which would allow to change
>> >> > > btime (on any filesystem)? This would at least make the consistency.
>> >> 
>> >> Pali, I think this is a very bad idea.
>> >
>> > Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
>> >
>> >> This has nothing to do with capabilities.
>> >> The Windows and MacOS filesystems have allowed setting their
>> >> "creation time" forever
>> >
>> > FreeBSD for some fs allow it too (see below).
>> >
>> >> and for all the other Linux filesystems that had
>> >> "birth time" it was immutable, so let's not mix filesystem features
>> >> with capabilities.
>> >
>> > I think that it is important to first define behavior and invariants of
>> > these "btime" and "ptime" kernel properties.
>> >
>> > If we want to be consistent then there are two possible options:
>> >
>> > 1. If we choose that the STATX_BTIME is immutable then no kernel fs
>> >    driver should allow to change.
>> >
>> > 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
>> >    then STATX_BTIME is not immutable at all.
>> >
>> > These two options cannot be chosen together because option 1 would
>> > implie that the modifiable "NTFS create time" cannot be reported over
>> > STATX_BTIME.
>> >
>> > We are have currently STATX_BTIME immutable and "NTFS create time"
>> > reported via STATX_BTIME.
>> >
>> > If we want to stay _consistent_ across fs drivers then adding API for
>> > changing "NTFS create time" would break one of those two things.
>> >
>> > In my opinion we should stay consistent across filesystem drivers and
>> > provide unified behavior of APIs independently of used filesystem.
>> > Otherwise userspace applications would have to write fs specific code
>> > for doing their use cases (and we can stay with fs-specific xattrs, no
>> > need to create unified APIs).
>> >
>> > Does it make sense? Or it is still a bad idea to think about it in this way?
>> 
>> Personally I think in this discussion we should separate linux
>> filesystems vs non-linux filesystems, as linux filesystems are "ours"
>> and are the ones we can change as we want, while non-linux filesystems
>> are not made by "us" and cannot be easily changed (like NFS I would say)
>> or cannot changed at all (e.g. NTFS (well, unless we make ntfs
>> incompatible with windows lol)).
>> 
>> But I understand why it would be better to keep a unified API across all
>> filesystems, even "non-official" ones, so I can think of 2 options
>> (well, with ntfs/exfat in mind, as I don't know much about NFS/smb):
>
> SMB for timestamps has exactly same meaning and storage format as NTFS.
> So it should be pretty straightforward what to do with it.
> NFS3 does not have btime at all. And NFS4 has FATTR4_TIME_CREATE attr
> which I described in previous email (there is no more info). So based on
> the decision of 1 or 2, that NFS4 attr would either map to btime or ptime.

Ah ok, thanks.

>> 
>> 1) keep btime aliased to ptime, which means that (to userspace) btime
>>    would be mutable for ntfs/exfat/vfat/etc
>> 
>> 2) move ntfs/exfat/vfat/etc's cr_time from btime to ptime, effectively
>>    "removing" btime from those FSs and "keeping" only ptime; in this case
>>    stat would show "-" for Birth:, but would show the correct timestamp for
>>    Origin:/Create:/Provenance:/...
>> 
>> I prefer 1) because it probably breaks less scripts, but 2) would be
>> more correct semantically.
>
> My personal opinion is 2) because the btime stay immutable also in
> userspace and is also more correct semantically.
>
> Another argument why 2) should be less breaking change: Userspace
> applications have to already expect that the btime is not filled at all
> (e.g. when filesystem does not support it or when application is running
> on older kernel version without such support).

Right, I didn't think of that.

> My opinion is that if the _new_ API provides two different timestamps
> based on the filesystem then we should report it as is, so userspace can
> decide how to want to process them. For example full 1:1 clone backup
> application would want to preserve both btime and ptime and correctly
> indicate if one of them is not available (e.g. because underlying fs
> support only one of those times, like NTFS). And such full 1:1 clone
> backup application do not want to "invent" some unavailable values.
> Option 1) would not allow to do that for such applications.

Ok yes I agree, I'll update the ntfs/exfat patches to switch btime for
ptime then.

>> And both break at least 1 existing script anyway (as per https://xkcd.com/1172/).
>
> Yes. And that is because we want a new feature which allows changing
> something which was immutable. So we need to handle it somehow.
>
>> >> >
>> >> > I think the ext4 and xfs maintainers have repeatedly said that btime/crtime
>> >> > attribute should not be modified by users.  There was a long discussion on
>> >> > this from Ted as well, and the reality is that "creation" time is not worth
>> >> > the bits that it is written on,
>> >> 
>> >> This is an opinion of individual people, who did not lay out technical
>> >> arguments.
>> >> I have concrete technical arguments in favor of first class creation time for
>> >> ext4/xfs from my experience with production systems that need it and use xattr
>> >> to store it (by smbd), but I am not going to list them here because
>> >> this is not a
>> >> thread about implementing mutable creation time for ext4/xfs.
>> 
>> For my (backups, preservation) use case, making btime mutable would also
>> be fine, but I can see the value of having a "ctime" for creation, hence
>> this RFC.
>> 
>> >> 
>> >> > since it is not preserved by any tools, has
>> >> 
>> >> Facts check:
>> >> 
>> >> # NEWS for rsync 3.2.3 (6 Aug 2020)
>> >> 
>> >> ## Changes in this version:
>> >> ...
>> >>  - Added [`--crtimes`](rsync.1#opt) (`-N`) option for preserving the file's
>> >>    create time (I believe that this is macOS only at the moment).
>> >> 
>> >> Incidentally, I have an implementation for --crtimes for cifs [1], but this
>> >> is not extendable to support all the filsystems which support settable crtime.
>> >
>> > Another two facts check:
>> >
>> > FreeBSD has also API for changing "birth (creation) times".
>> > It is documented in utimes(2) manpage:
>> > https://man.freebsd.org/cgi/man.cgi?query=utimes&sektion=2
>> >
>> > So I guess that there has to be some tool which is using this API and
>> > therefore these "birth (creation) times" are preserved.
>> >
>> >
>> > NFS4 has time_create attribute (FATTR4_TIME_CREATE=50) which is
>> > per-fs-object read-write attribute and defined (in RFC8881 5.8.2.40.) as:
>> >   The time of creation of the object. This attribute does not have any
>> >   relation to the traditional UNIX file attribute "ctime" or "change time".
>> > Since NFSv4.1 it can be even specified during creating a new file/dir
>> > which seems to be for backup-restore. And permissions (RFC8881 6.2.1.3.1.):
>> >   ACE4_WRITE_ATTRIBUTES
>> >   Operation(s) affected: SETATTR of time_access_set, time_backup,
>> >     time_create, time_modify_set, mimetype, hidden, system
>> >   Discussion: Permission to change the times associated with a file or
>> >     directory to an arbitrary value. Also permission to change the
>> >     mimetype, hidden, and system attributes. A user having ACE4_WRITE_DATA
>> >     or ACE4_WRITE_ATTRIBUTES will be allowed to set the times associated
>> >     with a file to the current server time.
>> >
>> > I'm not sure if there is some backup/restore tool which do it over NFS4
>> > but the NFS4 description seems to be very clear that the network protocol
>> > itself is already prepared for these use cases. And permissions mostly
>> > matches the SMB / NTFS / Windows security model.
>> >
>> >> > a "vague" meaning (is it when the *file* was created, when the *content* was
>> >> > created, do edits update it, is it preserved across filesystems, archives,
>> >> > etc.) and adding it into the filesystem is misplaced effort.
>> >> 
>> >> Sorry now you are talking nonsense. Meaning has nothing to do with it.
>> >> This is a property of filesystems (plural) which have documented APIs
>> >> and documented network protocols - it is what it is.
>> >> 
>> >> If you are looking for a meaning, it is the first publication date, whether
>> >> it means something to you is irrelevant - what's relevant is that customers
>> >> use it and want to preserve it in backups, whatever its meaning is.
>> >
>> > I agree here. I also heard lot of times that users (customers) want to
>> > preserve create time in backups and be able to restore it. And that
>> > Windows is already able to do it, Linux not yet.
>> 
>> Hi I'm one of those users, I still can't believe no-one has implemented
>> something like this yet since POSIX came out way back when (*cry*).
>> 
>> > Maybe what is a "vague" here is where that "create time" is stored and
>> > from which (API) source is GUI (or CLI) application showing it to user.
>> >
>> >> >
>> >> > Storing it as an xattr has some reasonable chance of being preserved across
>> >> > tar/cp/filesystems, and doesn't introduce a herculean effort of changing
>> >> > all of the system calls and on-disk formats for every filesystem.
>> >> >
>> >
>> > I think the part "being preserved across tar/cp/filesystems" is
>> > relevant. If a completely new API is introduced into Linux then it means
>> > that every existing backup tool would not be able to preserve this
>> > property and also would not be able to restore it.
>> >
>> > I'm not sure if we can do anything with this issue, but it is important
>> > to know about this limitation.
>> 
>> My thinking for this RFC would be to then submit relevant patches also
>> to at least the main tools I use like tar, cp, rsync and vim, which will
>> hopefully make it gain momentum and be supported also in other less
>> well-known tools (I would also love for it to be supported by HTTP like
>> mtime is, but that will likely be a lot more difficult to get accepted
>> and implemented).
>
> If having two btime and ptime fields would be the direction then we can
> propose an extension for NFS4 protocol with a new attribute (as NFS4 has
> currently only one). There are already some NFS4 extensions which comes
> from Linux or was inspired, e.g. umask or xattr support.

Yes that would be nice, so when making the patch for nfs (in v4 or v5),
should I treat FATTR4_TIME_CREATE as ptime and maybe try to add the
needed code for a new btime?

Thanks,
koraynilay

>> > About the part "introduce a herculean effort of changing all of the
>> > system calls and on-disk formats for every filesystem.". In my opinion
>> > it is better to do that cleanup (maybe even in all stat-related
>> > syscalls) if it makes things easier and prevents another technical
>> > issues.
>> >
>> >> 
>> >> As I said I can provide data for why the xattr approach taken by smbd is
>> >> limited and inferior, but this is not the place to get into it (there are hints
>> >> in the rsync commit message below).
>> >> 
>> >> Thanks,
>> >> Amir.
>> >> 
>> >> [1] https://github.com/amir73il/rsync/commits/cifs-crtimes/
>> >
>> > I would say that xattr does not solve this issue too.
>> 
>> I would also like to note again that xattrs aren't available to symlinks
>> (or other special files), which would break at least my backup/preservation
>> use case.
>> 
>> Best,
>> koraynilay

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Pali Rohár]

On Tuesday 03 November 2026 13:11:30 koraynilay wrote:
> On Tue Nov 3, 2026 at 12:38 PM CET, Pali Rohár wrote:
> > On Tuesday 03 November 2026 12:04:39 koraynilay wrote:
> >> Hi and sorry for the late reply,
> >> 
> >> On Tue Nov 3, 2026 at 10:49 AM CET, Pali Rohár wrote:
> >> > On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
> >> >> On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
> >> >> >
> >> >> > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
> >> >> > >
> >> >> > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
> >> >> > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
> >> >> > >>>
> >> >> > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> >> >> > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> >> >> > >>>>      if (flags & FS_APPEND_FL)
> >> >> > >>>>              new_fl |= S_APPEND;
> >> >> > >>>>
> >> >> > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> >> >> > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> >> >> > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> >> >> > >>>> +     }
> >> >> > >>>> +
> >> >> > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> >> >> > >>>>
> >> >> > >>>>      /* Save nodump flag to return in ntfs_getattr. */
> >> >> > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> >> >> > >>>>      if (unlikely(is_bad_ni(ni)))
> >> >> > >>>>              return -EINVAL;
> >> >> > >>>>
> >> >> > >>>> -     stat->result_mask |= STATX_BTIME;
> >> >> > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> >> >> > >>>>      stat->btime = ni->i_crtime;
> >> >> > >>>> +     stat->ptime = ni->i_crtime;
> >> >> > >>>
> >> >> > >>> For me this patch looks dangerous. Somehow I would expect that the
> >> >> > >>> "btime" will never change for existing inode.
> >> >> > >>>
> >> >> > >>> But because the ptime is mapped to i_crtime and ptime is settable from
> >> >> > >>> userspace, with this patch it is directly possible to change btime.
> >> >> > >>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> I was thinking more about it... Is not this just misunderstanding of how
> >> >> > >>> the security model around the times is working on different systems?
> >> >> > >>> Because on NTFS there is stored just one field which says when the file
> >> >> > >>> was created. There are not two fields like "time set by user and time
> >> >> > >>> set by system".
> >> >> > >>>
> >> >> > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
> >> >> > >>> change that create time. Linux security model does not allow to change it.
> >> >> > >>>
> >> >> > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> >> >> > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
> >> >> > >>> on Windows systems, then Windows security model should handle it in the
> >> >> > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> >> >> > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
> >> >> > >>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> On the other hand, I understand the use case to have two creation times.
> >> >> > >>> One time which would never be changed and could be used for any kind of
> >> >> > >>> atomic / synchronization by userspace application logic (this btime).
> >> >> > >>> And another time for human which can be changed at any time to any value
> >> >> > >>> which user wants (this ptime).
> >> >> > >>>
> >> >> > >>> In any case, I would suggest that filesystem driver would not report to
> >> >> > >>> userspace unsupported values and would not try to invent other values
> >> >> > >>> and lying about them.
> >> >> > >>
> >> >> > >> But all those fs with mutable creation time already report it with STATX_BTIME
> >> >> > >> so what can we do about this?
> >> >> > >
> >> >> > > Well, what I wanted above to point out is that the "mutability" of
> >> >> > > creation time is not feature of filesystem, but in my opinion rather
> >> >> > > property of the security model on the running operating system.
> >> >> > >
> >> >> > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
> >> >> > > In my opinion there is no much difference, both of them has meaning
> >> >> > > "time when was the file created".
> >> >> > >
> >> >> > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
> >> >> > >> those fs could technically return only STATX_PTIME and it should not regress
> >> >> > >> existing programs.
> >> >> > >>
> >> >> > >> But this is still a bit surprising behavior is it not?
> >> >> > >>
> >> >> > >> Thanks,
> >> >> > >> Amir.
> >> >> > >
> >> >> > > I'm not sure what to do with it.
> >> >> > >
> >> >> > > If we allow to change btime of ntfs then for consistency we should also
> >> >> > > allow to change btime of ext4.
> >> >> > >
> >> >> > > Maybe another idea... define new capability which would allow to change
> >> >> > > btime (on any filesystem)? This would at least make the consistency.
> >> >> 
> >> >> Pali, I think this is a very bad idea.
> >> >
> >> > Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
> >> >
> >> >> This has nothing to do with capabilities.
> >> >> The Windows and MacOS filesystems have allowed setting their
> >> >> "creation time" forever
> >> >
> >> > FreeBSD for some fs allow it too (see below).
> >> >
> >> >> and for all the other Linux filesystems that had
> >> >> "birth time" it was immutable, so let's not mix filesystem features
> >> >> with capabilities.
> >> >
> >> > I think that it is important to first define behavior and invariants of
> >> > these "btime" and "ptime" kernel properties.
> >> >
> >> > If we want to be consistent then there are two possible options:
> >> >
> >> > 1. If we choose that the STATX_BTIME is immutable then no kernel fs
> >> >    driver should allow to change.
> >> >
> >> > 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
> >> >    then STATX_BTIME is not immutable at all.
> >> >
> >> > These two options cannot be chosen together because option 1 would
> >> > implie that the modifiable "NTFS create time" cannot be reported over
> >> > STATX_BTIME.
> >> >
> >> > We are have currently STATX_BTIME immutable and "NTFS create time"
> >> > reported via STATX_BTIME.
> >> >
> >> > If we want to stay _consistent_ across fs drivers then adding API for
> >> > changing "NTFS create time" would break one of those two things.
> >> >
> >> > In my opinion we should stay consistent across filesystem drivers and
> >> > provide unified behavior of APIs independently of used filesystem.
> >> > Otherwise userspace applications would have to write fs specific code
> >> > for doing their use cases (and we can stay with fs-specific xattrs, no
> >> > need to create unified APIs).
> >> >
> >> > Does it make sense? Or it is still a bad idea to think about it in this way?
> >> 
> >> Personally I think in this discussion we should separate linux
> >> filesystems vs non-linux filesystems, as linux filesystems are "ours"
> >> and are the ones we can change as we want, while non-linux filesystems
> >> are not made by "us" and cannot be easily changed (like NFS I would say)
> >> or cannot changed at all (e.g. NTFS (well, unless we make ntfs
> >> incompatible with windows lol)).
> >> 
> >> But I understand why it would be better to keep a unified API across all
> >> filesystems, even "non-official" ones, so I can think of 2 options
> >> (well, with ntfs/exfat in mind, as I don't know much about NFS/smb):
> >
> > SMB for timestamps has exactly same meaning and storage format as NTFS.
> > So it should be pretty straightforward what to do with it.
> > NFS3 does not have btime at all. And NFS4 has FATTR4_TIME_CREATE attr
> > which I described in previous email (there is no more info). So based on
> > the decision of 1 or 2, that NFS4 attr would either map to btime or ptime.
> 
> Ah ok, thanks.
> 
> >> 
> >> 1) keep btime aliased to ptime, which means that (to userspace) btime
> >>    would be mutable for ntfs/exfat/vfat/etc
> >> 
> >> 2) move ntfs/exfat/vfat/etc's cr_time from btime to ptime, effectively
> >>    "removing" btime from those FSs and "keeping" only ptime; in this case
> >>    stat would show "-" for Birth:, but would show the correct timestamp for
> >>    Origin:/Create:/Provenance:/...
> >> 
> >> I prefer 1) because it probably breaks less scripts, but 2) would be
> >> more correct semantically.
> >
> > My personal opinion is 2) because the btime stay immutable also in
> > userspace and is also more correct semantically.
> >
> > Another argument why 2) should be less breaking change: Userspace
> > applications have to already expect that the btime is not filled at all
> > (e.g. when filesystem does not support it or when application is running
> > on older kernel version without such support).
> 
> Right, I didn't think of that.
> 
> > My opinion is that if the _new_ API provides two different timestamps
> > based on the filesystem then we should report it as is, so userspace can
> > decide how to want to process them. For example full 1:1 clone backup
> > application would want to preserve both btime and ptime and correctly
> > indicate if one of them is not available (e.g. because underlying fs
> > support only one of those times, like NTFS). And such full 1:1 clone
> > backup application do not want to "invent" some unavailable values.
> > Option 1) would not allow to do that for such applications.
> 
> Ok yes I agree, I'll update the ntfs/exfat patches to switch btime for
> ptime then.

Well, what I wrote is my personal opinion, not the decision from this list.

> >> And both break at least 1 existing script anyway (as per https://xkcd.com/1172/).
> >
> > Yes. And that is because we want a new feature which allows changing
> > something which was immutable. So we need to handle it somehow.
> >
> >> >> >
> >> >> > I think the ext4 and xfs maintainers have repeatedly said that btime/crtime
> >> >> > attribute should not be modified by users.  There was a long discussion on
> >> >> > this from Ted as well, and the reality is that "creation" time is not worth
> >> >> > the bits that it is written on,
> >> >> 
> >> >> This is an opinion of individual people, who did not lay out technical
> >> >> arguments.
> >> >> I have concrete technical arguments in favor of first class creation time for
> >> >> ext4/xfs from my experience with production systems that need it and use xattr
> >> >> to store it (by smbd), but I am not going to list them here because
> >> >> this is not a
> >> >> thread about implementing mutable creation time for ext4/xfs.
> >> 
> >> For my (backups, preservation) use case, making btime mutable would also
> >> be fine, but I can see the value of having a "ctime" for creation, hence
> >> this RFC.
> >> 
> >> >> 
> >> >> > since it is not preserved by any tools, has
> >> >> 
> >> >> Facts check:
> >> >> 
> >> >> # NEWS for rsync 3.2.3 (6 Aug 2020)
> >> >> 
> >> >> ## Changes in this version:
> >> >> ...
> >> >>  - Added [`--crtimes`](rsync.1#opt) (`-N`) option for preserving the file's
> >> >>    create time (I believe that this is macOS only at the moment).
> >> >> 
> >> >> Incidentally, I have an implementation for --crtimes for cifs [1], but this
> >> >> is not extendable to support all the filsystems which support settable crtime.
> >> >
> >> > Another two facts check:
> >> >
> >> > FreeBSD has also API for changing "birth (creation) times".
> >> > It is documented in utimes(2) manpage:
> >> > https://man.freebsd.org/cgi/man.cgi?query=utimes&sektion=2
> >> >
> >> > So I guess that there has to be some tool which is using this API and
> >> > therefore these "birth (creation) times" are preserved.
> >> >
> >> >
> >> > NFS4 has time_create attribute (FATTR4_TIME_CREATE=50) which is
> >> > per-fs-object read-write attribute and defined (in RFC8881 5.8.2.40.) as:
> >> >   The time of creation of the object. This attribute does not have any
> >> >   relation to the traditional UNIX file attribute "ctime" or "change time".
> >> > Since NFSv4.1 it can be even specified during creating a new file/dir
> >> > which seems to be for backup-restore. And permissions (RFC8881 6.2.1.3.1.):
> >> >   ACE4_WRITE_ATTRIBUTES
> >> >   Operation(s) affected: SETATTR of time_access_set, time_backup,
> >> >     time_create, time_modify_set, mimetype, hidden, system
> >> >   Discussion: Permission to change the times associated with a file or
> >> >     directory to an arbitrary value. Also permission to change the
> >> >     mimetype, hidden, and system attributes. A user having ACE4_WRITE_DATA
> >> >     or ACE4_WRITE_ATTRIBUTES will be allowed to set the times associated
> >> >     with a file to the current server time.
> >> >
> >> > I'm not sure if there is some backup/restore tool which do it over NFS4
> >> > but the NFS4 description seems to be very clear that the network protocol
> >> > itself is already prepared for these use cases. And permissions mostly
> >> > matches the SMB / NTFS / Windows security model.
> >> >
> >> >> > a "vague" meaning (is it when the *file* was created, when the *content* was
> >> >> > created, do edits update it, is it preserved across filesystems, archives,
> >> >> > etc.) and adding it into the filesystem is misplaced effort.
> >> >> 
> >> >> Sorry now you are talking nonsense. Meaning has nothing to do with it.
> >> >> This is a property of filesystems (plural) which have documented APIs
> >> >> and documented network protocols - it is what it is.
> >> >> 
> >> >> If you are looking for a meaning, it is the first publication date, whether
> >> >> it means something to you is irrelevant - what's relevant is that customers
> >> >> use it and want to preserve it in backups, whatever its meaning is.
> >> >
> >> > I agree here. I also heard lot of times that users (customers) want to
> >> > preserve create time in backups and be able to restore it. And that
> >> > Windows is already able to do it, Linux not yet.
> >> 
> >> Hi I'm one of those users, I still can't believe no-one has implemented
> >> something like this yet since POSIX came out way back when (*cry*).
> >> 
> >> > Maybe what is a "vague" here is where that "create time" is stored and
> >> > from which (API) source is GUI (or CLI) application showing it to user.
> >> >
> >> >> >
> >> >> > Storing it as an xattr has some reasonable chance of being preserved across
> >> >> > tar/cp/filesystems, and doesn't introduce a herculean effort of changing
> >> >> > all of the system calls and on-disk formats for every filesystem.
> >> >> >
> >> >
> >> > I think the part "being preserved across tar/cp/filesystems" is
> >> > relevant. If a completely new API is introduced into Linux then it means
> >> > that every existing backup tool would not be able to preserve this
> >> > property and also would not be able to restore it.
> >> >
> >> > I'm not sure if we can do anything with this issue, but it is important
> >> > to know about this limitation.
> >> 
> >> My thinking for this RFC would be to then submit relevant patches also
> >> to at least the main tools I use like tar, cp, rsync and vim, which will
> >> hopefully make it gain momentum and be supported also in other less
> >> well-known tools (I would also love for it to be supported by HTTP like
> >> mtime is, but that will likely be a lot more difficult to get accepted
> >> and implemented).
> >
> > If having two btime and ptime fields would be the direction then we can
> > propose an extension for NFS4 protocol with a new attribute (as NFS4 has
> > currently only one). There are already some NFS4 extensions which comes
> > from Linux or was inspired, e.g. umask or xattr support.
> 
> Yes that would be nice, so when making the patch for nfs (in v4 or v5),
> should I treat FATTR4_TIME_CREATE as ptime and maybe try to add the
> needed code for a new btime?

That is good question and I do not have any definite answer how should
Linux handle it.

The reason is very simple. If you look at the FATTR4_TIME_CREATE in
specification (basically I have copied everything about it in previous
emails) it is short and does not say which one it should be.

I was implementing commercial NFS+SMB server with a hard requirement on
compliance with both protocols at the same time and also interop between
them. So from this my perspective by reading NFS4 spec with knowledge of
how SMB server should behave and how are designed Windows/SMB attributes
and permissions into NFS4, if I was asked to which of "ptime" or "btime"
I should map the FATTR4_TIME_CREATE then I would say it is "ptime".
Reasons: all those time attributes are R/W (like in SMB/Windows),
all of them require WRITE_ATTRIBUTES acl permission (like in SMB/Windows)
and we somehow agreed that Windows "create time" matches the "ptime",
and also because the request from from SMB to change create time would
not result in changing the linux "immutable btime". Basically in that
NFS4 spec I see a connection between FATTR4_TIME_CREATE and SMB create time.

But please this my analysis not from the Linux perspective, but rather
from the FS server perspective with respect to the NFS4 and SMB protocols.
I'm just giving inputs here.

> Thanks,
> koraynilay
> 
> >> > About the part "introduce a herculean effort of changing all of the
> >> > system calls and on-disk formats for every filesystem.". In my opinion
> >> > it is better to do that cleanup (maybe even in all stat-related
> >> > syscalls) if it makes things easier and prevents another technical
> >> > issues.
> >> >
> >> >> 
> >> >> As I said I can provide data for why the xattr approach taken by smbd is
> >> >> limited and inferior, but this is not the place to get into it (there are hints
> >> >> in the rsync commit message below).
> >> >> 
> >> >> Thanks,
> >> >> Amir.
> >> >> 
> >> >> [1] https://github.com/amir73il/rsync/commits/cifs-crtimes/
> >> >
> >> > I would say that xattr does not solve this issue too.
> >> 
> >> I would also like to note again that xattrs aren't available to symlinks
> >> (or other special files), which would break at least my backup/preservation
> >> use case.
> >> 
> >> Best,
> >> koraynilay

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 19646 bytes --]

On Tue Nov 3, 2026 at 1:48 PM CET, Pali Rohár wrote:
> On Tuesday 03 November 2026 13:11:30 koraynilay wrote:
>> On Tue Nov 3, 2026 at 12:38 PM CET, Pali Rohár wrote:
>> > On Tuesday 03 November 2026 12:04:39 koraynilay wrote:
>> >> Hi and sorry for the late reply,
>> >> 
>> >> On Tue Nov 3, 2026 at 10:49 AM CET, Pali Rohár wrote:
>> >> > On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
>> >> >> On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
>> >> >> >
>> >> >> > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
>> >> >> > >
>> >> >> > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
>> >> >> > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
>> >> >> > >>>
>> >> >> > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
>> >> >> > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
>> >> >> > >>>>      if (flags & FS_APPEND_FL)
>> >> >> > >>>>              new_fl |= S_APPEND;
>> >> >> > >>>>
>> >> >> > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
>> >> >> > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
>> >> >> > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
>> >> >> > >>>> +     }
>> >> >> > >>>> +
>> >> >> > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
>> >> >> > >>>>
>> >> >> > >>>>      /* Save nodump flag to return in ntfs_getattr. */
>> >> >> > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
>> >> >> > >>>>      if (unlikely(is_bad_ni(ni)))
>> >> >> > >>>>              return -EINVAL;
>> >> >> > >>>>
>> >> >> > >>>> -     stat->result_mask |= STATX_BTIME;
>> >> >> > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
>> >> >> > >>>>      stat->btime = ni->i_crtime;
>> >> >> > >>>> +     stat->ptime = ni->i_crtime;
>> >> >> > >>>
>> >> >> > >>> For me this patch looks dangerous. Somehow I would expect that the
>> >> >> > >>> "btime" will never change for existing inode.
>> >> >> > >>>
>> >> >> > >>> But because the ptime is mapped to i_crtime and ptime is settable from
>> >> >> > >>> userspace, with this patch it is directly possible to change btime.
>> >> >> > >>>
>> >> >> > >>>
>> >> >> > >>>
>> >> >> > >>> I was thinking more about it... Is not this just misunderstanding of how
>> >> >> > >>> the security model around the times is working on different systems?
>> >> >> > >>> Because on NTFS there is stored just one field which says when the file
>> >> >> > >>> was created. There are not two fields like "time set by user and time
>> >> >> > >>> set by system".
>> >> >> > >>>
>> >> >> > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
>> >> >> > >>> change that create time. Linux security model does not allow to change it.
>> >> >> > >>>
>> >> >> > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
>> >> >> > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
>> >> >> > >>> on Windows systems, then Windows security model should handle it in the
>> >> >> > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
>> >> >> > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
>> >> >> > >>>
>> >> >> > >>>
>> >> >> > >>>
>> >> >> > >>> On the other hand, I understand the use case to have two creation times.
>> >> >> > >>> One time which would never be changed and could be used for any kind of
>> >> >> > >>> atomic / synchronization by userspace application logic (this btime).
>> >> >> > >>> And another time for human which can be changed at any time to any value
>> >> >> > >>> which user wants (this ptime).
>> >> >> > >>>
>> >> >> > >>> In any case, I would suggest that filesystem driver would not report to
>> >> >> > >>> userspace unsupported values and would not try to invent other values
>> >> >> > >>> and lying about them.
>> >> >> > >>
>> >> >> > >> But all those fs with mutable creation time already report it with STATX_BTIME
>> >> >> > >> so what can we do about this?
>> >> >> > >
>> >> >> > > Well, what I wanted above to point out is that the "mutability" of
>> >> >> > > creation time is not feature of filesystem, but in my opinion rather
>> >> >> > > property of the security model on the running operating system.
>> >> >> > >
>> >> >> > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
>> >> >> > > In my opinion there is no much difference, both of them has meaning
>> >> >> > > "time when was the file created".
>> >> >> > >
>> >> >> > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
>> >> >> > >> those fs could technically return only STATX_PTIME and it should not regress
>> >> >> > >> existing programs.
>> >> >> > >>
>> >> >> > >> But this is still a bit surprising behavior is it not?
>> >> >> > >>
>> >> >> > >> Thanks,
>> >> >> > >> Amir.
>> >> >> > >
>> >> >> > > I'm not sure what to do with it.
>> >> >> > >
>> >> >> > > If we allow to change btime of ntfs then for consistency we should also
>> >> >> > > allow to change btime of ext4.
>> >> >> > >
>> >> >> > > Maybe another idea... define new capability which would allow to change
>> >> >> > > btime (on any filesystem)? This would at least make the consistency.
>> >> >> 
>> >> >> Pali, I think this is a very bad idea.
>> >> >
>> >> > Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
>> >> >
>> >> >> This has nothing to do with capabilities.
>> >> >> The Windows and MacOS filesystems have allowed setting their
>> >> >> "creation time" forever
>> >> >
>> >> > FreeBSD for some fs allow it too (see below).
>> >> >
>> >> >> and for all the other Linux filesystems that had
>> >> >> "birth time" it was immutable, so let's not mix filesystem features
>> >> >> with capabilities.
>> >> >
>> >> > I think that it is important to first define behavior and invariants of
>> >> > these "btime" and "ptime" kernel properties.
>> >> >
>> >> > If we want to be consistent then there are two possible options:
>> >> >
>> >> > 1. If we choose that the STATX_BTIME is immutable then no kernel fs
>> >> >    driver should allow to change.
>> >> >
>> >> > 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
>> >> >    then STATX_BTIME is not immutable at all.
>> >> >
>> >> > These two options cannot be chosen together because option 1 would
>> >> > implie that the modifiable "NTFS create time" cannot be reported over
>> >> > STATX_BTIME.
>> >> >
>> >> > We are have currently STATX_BTIME immutable and "NTFS create time"
>> >> > reported via STATX_BTIME.
>> >> >
>> >> > If we want to stay _consistent_ across fs drivers then adding API for
>> >> > changing "NTFS create time" would break one of those two things.
>> >> >
>> >> > In my opinion we should stay consistent across filesystem drivers and
>> >> > provide unified behavior of APIs independently of used filesystem.
>> >> > Otherwise userspace applications would have to write fs specific code
>> >> > for doing their use cases (and we can stay with fs-specific xattrs, no
>> >> > need to create unified APIs).
>> >> >
>> >> > Does it make sense? Or it is still a bad idea to think about it in this way?
>> >> 
>> >> Personally I think in this discussion we should separate linux
>> >> filesystems vs non-linux filesystems, as linux filesystems are "ours"
>> >> and are the ones we can change as we want, while non-linux filesystems
>> >> are not made by "us" and cannot be easily changed (like NFS I would say)
>> >> or cannot changed at all (e.g. NTFS (well, unless we make ntfs
>> >> incompatible with windows lol)).
>> >> 
>> >> But I understand why it would be better to keep a unified API across all
>> >> filesystems, even "non-official" ones, so I can think of 2 options
>> >> (well, with ntfs/exfat in mind, as I don't know much about NFS/smb):
>> >
>> > SMB for timestamps has exactly same meaning and storage format as NTFS.
>> > So it should be pretty straightforward what to do with it.
>> > NFS3 does not have btime at all. And NFS4 has FATTR4_TIME_CREATE attr
>> > which I described in previous email (there is no more info). So based on
>> > the decision of 1 or 2, that NFS4 attr would either map to btime or ptime.
>> 
>> Ah ok, thanks.
>> 
>> >> 
>> >> 1) keep btime aliased to ptime, which means that (to userspace) btime
>> >>    would be mutable for ntfs/exfat/vfat/etc
>> >> 
>> >> 2) move ntfs/exfat/vfat/etc's cr_time from btime to ptime, effectively
>> >>    "removing" btime from those FSs and "keeping" only ptime; in this case
>> >>    stat would show "-" for Birth:, but would show the correct timestamp for
>> >>    Origin:/Create:/Provenance:/...
>> >> 
>> >> I prefer 1) because it probably breaks less scripts, but 2) would be
>> >> more correct semantically.
>> >
>> > My personal opinion is 2) because the btime stay immutable also in
>> > userspace and is also more correct semantically.
>> >
>> > Another argument why 2) should be less breaking change: Userspace
>> > applications have to already expect that the btime is not filled at all
>> > (e.g. when filesystem does not support it or when application is running
>> > on older kernel version without such support).
>> 
>> Right, I didn't think of that.
>> 
>> > My opinion is that if the _new_ API provides two different timestamps
>> > based on the filesystem then we should report it as is, so userspace can
>> > decide how to want to process them. For example full 1:1 clone backup
>> > application would want to preserve both btime and ptime and correctly
>> > indicate if one of them is not available (e.g. because underlying fs
>> > support only one of those times, like NTFS). And such full 1:1 clone
>> > backup application do not want to "invent" some unavailable values.
>> > Option 1) would not allow to do that for such applications.
>> 
>> Ok yes I agree, I'll update the ntfs/exfat patches to switch btime for
>> ptime then.
>
> Well, what I wrote is my personal opinion, not the decision from this list.

Right, I don't have a strong personal preference either way, so I'll
wait for more feedback (so there's also less diff between v3 and v4).

>> >> And both break at least 1 existing script anyway (as per https://xkcd.com/1172/).
>> >
>> > Yes. And that is because we want a new feature which allows changing
>> > something which was immutable. So we need to handle it somehow.
>> >
>> >> >> >
>> >> >> > I think the ext4 and xfs maintainers have repeatedly said that btime/crtime
>> >> >> > attribute should not be modified by users.  There was a long discussion on
>> >> >> > this from Ted as well, and the reality is that "creation" time is not worth
>> >> >> > the bits that it is written on,
>> >> >> 
>> >> >> This is an opinion of individual people, who did not lay out technical
>> >> >> arguments.
>> >> >> I have concrete technical arguments in favor of first class creation time for
>> >> >> ext4/xfs from my experience with production systems that need it and use xattr
>> >> >> to store it (by smbd), but I am not going to list them here because
>> >> >> this is not a
>> >> >> thread about implementing mutable creation time for ext4/xfs.
>> >> 
>> >> For my (backups, preservation) use case, making btime mutable would also
>> >> be fine, but I can see the value of having a "ctime" for creation, hence
>> >> this RFC.
>> >> 
>> >> >> 
>> >> >> > since it is not preserved by any tools, has
>> >> >> 
>> >> >> Facts check:
>> >> >> 
>> >> >> # NEWS for rsync 3.2.3 (6 Aug 2020)
>> >> >> 
>> >> >> ## Changes in this version:
>> >> >> ...
>> >> >>  - Added [`--crtimes`](rsync.1#opt) (`-N`) option for preserving the file's
>> >> >>    create time (I believe that this is macOS only at the moment).
>> >> >> 
>> >> >> Incidentally, I have an implementation for --crtimes for cifs [1], but this
>> >> >> is not extendable to support all the filsystems which support settable crtime.
>> >> >
>> >> > Another two facts check:
>> >> >
>> >> > FreeBSD has also API for changing "birth (creation) times".
>> >> > It is documented in utimes(2) manpage:
>> >> > https://man.freebsd.org/cgi/man.cgi?query=utimes&sektion=2
>> >> >
>> >> > So I guess that there has to be some tool which is using this API and
>> >> > therefore these "birth (creation) times" are preserved.
>> >> >
>> >> >
>> >> > NFS4 has time_create attribute (FATTR4_TIME_CREATE=50) which is
>> >> > per-fs-object read-write attribute and defined (in RFC8881 5.8.2.40.) as:
>> >> >   The time of creation of the object. This attribute does not have any
>> >> >   relation to the traditional UNIX file attribute "ctime" or "change time".
>> >> > Since NFSv4.1 it can be even specified during creating a new file/dir
>> >> > which seems to be for backup-restore. And permissions (RFC8881 6.2.1.3.1.):
>> >> >   ACE4_WRITE_ATTRIBUTES
>> >> >   Operation(s) affected: SETATTR of time_access_set, time_backup,
>> >> >     time_create, time_modify_set, mimetype, hidden, system
>> >> >   Discussion: Permission to change the times associated with a file or
>> >> >     directory to an arbitrary value. Also permission to change the
>> >> >     mimetype, hidden, and system attributes. A user having ACE4_WRITE_DATA
>> >> >     or ACE4_WRITE_ATTRIBUTES will be allowed to set the times associated
>> >> >     with a file to the current server time.
>> >> >
>> >> > I'm not sure if there is some backup/restore tool which do it over NFS4
>> >> > but the NFS4 description seems to be very clear that the network protocol
>> >> > itself is already prepared for these use cases. And permissions mostly
>> >> > matches the SMB / NTFS / Windows security model.
>> >> >
>> >> >> > a "vague" meaning (is it when the *file* was created, when the *content* was
>> >> >> > created, do edits update it, is it preserved across filesystems, archives,
>> >> >> > etc.) and adding it into the filesystem is misplaced effort.
>> >> >> 
>> >> >> Sorry now you are talking nonsense. Meaning has nothing to do with it.
>> >> >> This is a property of filesystems (plural) which have documented APIs
>> >> >> and documented network protocols - it is what it is.
>> >> >> 
>> >> >> If you are looking for a meaning, it is the first publication date, whether
>> >> >> it means something to you is irrelevant - what's relevant is that customers
>> >> >> use it and want to preserve it in backups, whatever its meaning is.
>> >> >
>> >> > I agree here. I also heard lot of times that users (customers) want to
>> >> > preserve create time in backups and be able to restore it. And that
>> >> > Windows is already able to do it, Linux not yet.
>> >> 
>> >> Hi I'm one of those users, I still can't believe no-one has implemented
>> >> something like this yet since POSIX came out way back when (*cry*).
>> >> 
>> >> > Maybe what is a "vague" here is where that "create time" is stored and
>> >> > from which (API) source is GUI (or CLI) application showing it to user.
>> >> >
>> >> >> >
>> >> >> > Storing it as an xattr has some reasonable chance of being preserved across
>> >> >> > tar/cp/filesystems, and doesn't introduce a herculean effort of changing
>> >> >> > all of the system calls and on-disk formats for every filesystem.
>> >> >> >
>> >> >
>> >> > I think the part "being preserved across tar/cp/filesystems" is
>> >> > relevant. If a completely new API is introduced into Linux then it means
>> >> > that every existing backup tool would not be able to preserve this
>> >> > property and also would not be able to restore it.
>> >> >
>> >> > I'm not sure if we can do anything with this issue, but it is important
>> >> > to know about this limitation.
>> >> 
>> >> My thinking for this RFC would be to then submit relevant patches also
>> >> to at least the main tools I use like tar, cp, rsync and vim, which will
>> >> hopefully make it gain momentum and be supported also in other less
>> >> well-known tools (I would also love for it to be supported by HTTP like
>> >> mtime is, but that will likely be a lot more difficult to get accepted
>> >> and implemented).
>> >
>> > If having two btime and ptime fields would be the direction then we can
>> > propose an extension for NFS4 protocol with a new attribute (as NFS4 has
>> > currently only one). There are already some NFS4 extensions which comes
>> > from Linux or was inspired, e.g. umask or xattr support.
>> 
>> Yes that would be nice, so when making the patch for nfs (in v4 or v5),
>> should I treat FATTR4_TIME_CREATE as ptime and maybe try to add the
>> needed code for a new btime?
>
> That is good question and I do not have any definite answer how should
> Linux handle it.
>
> The reason is very simple. If you look at the FATTR4_TIME_CREATE in
> specification (basically I have copied everything about it in previous
> emails) it is short and does not say which one it should be.
>
> I was implementing commercial NFS+SMB server with a hard requirement on
> compliance with both protocols at the same time and also interop between
> them. So from this my perspective by reading NFS4 spec with knowledge of
> how SMB server should behave and how are designed Windows/SMB attributes
> and permissions into NFS4, if I was asked to which of "ptime" or "btime"
> I should map the FATTR4_TIME_CREATE then I would say it is "ptime".
> Reasons: all those time attributes are R/W (like in SMB/Windows),
> all of them require WRITE_ATTRIBUTES acl permission (like in SMB/Windows)
> and we somehow agreed that Windows "create time" matches the "ptime",
> and also because the request from from SMB to change create time would
> not result in changing the linux "immutable btime". Basically in that
> NFS4 spec I see a connection between FATTR4_TIME_CREATE and SMB create time.
>
> But please this my analysis not from the Linux perspective, but rather
> from the FS server perspective with respect to the NFS4 and SMB protocols.
> I'm just giving inputs here.

I also agree that FATTR4_TIME_CREATE should map to ptime, mainly because
in the spec you posted it says it's user-settable with the right
permissions, while btime wouldn't be (and semantically it wouldn't make
sense to be able to, considering btime means "inode creation time").

Best,
koraynilay

>> Thanks,
>> koraynilay
>> 
>> >> > About the part "introduce a herculean effort of changing all of the
>> >> > system calls and on-disk formats for every filesystem.". In my opinion
>> >> > it is better to do that cleanup (maybe even in all stat-related
>> >> > syscalls) if it makes things easier and prevents another technical
>> >> > issues.
>> >> >
>> >> >> 
>> >> >> As I said I can provide data for why the xattr approach taken by smbd is
>> >> >> limited and inferior, but this is not the place to get into it (there are hints
>> >> >> in the rsync commit message below).
>> >> >> 
>> >> >> Thanks,
>> >> >> Amir.
>> >> >> 
>> >> >> [1] https://github.com/amir73il/rsync/commits/cifs-crtimes/
>> >> >
>> >> > I would say that xattr does not solve this issue too.
>> >> 
>> >> I would also like to note again that xattrs aren't available to symlinks
>> >> (or other special files), which would break at least my backup/preservation
>> >> use case.
>> >> 
>> >> Best,
>> >> koraynilay



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Amir Goldstein]

On Tue, Nov 3, 2026 at 10:49 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
> > On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
> > >
> > > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
> > > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
> > > >>>
> > > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> > > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> > > >>>>      if (flags & FS_APPEND_FL)
> > > >>>>              new_fl |= S_APPEND;
> > > >>>>
> > > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> > > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> > > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> > > >>>> +     }
> > > >>>> +
> > > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> > > >>>>
> > > >>>>      /* Save nodump flag to return in ntfs_getattr. */
> > > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> > > >>>>      if (unlikely(is_bad_ni(ni)))
> > > >>>>              return -EINVAL;
> > > >>>>
> > > >>>> -     stat->result_mask |= STATX_BTIME;
> > > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> > > >>>>      stat->btime = ni->i_crtime;
> > > >>>> +     stat->ptime = ni->i_crtime;
> > > >>>
> > > >>> For me this patch looks dangerous. Somehow I would expect that the
> > > >>> "btime" will never change for existing inode.
> > > >>>
> > > >>> But because the ptime is mapped to i_crtime and ptime is settable from
> > > >>> userspace, with this patch it is directly possible to change btime.
> > > >>>
> > > >>>
> > > >>>
> > > >>> I was thinking more about it... Is not this just misunderstanding of how
> > > >>> the security model around the times is working on different systems?
> > > >>> Because on NTFS there is stored just one field which says when the file
> > > >>> was created. There are not two fields like "time set by user and time
> > > >>> set by system".
> > > >>>
> > > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
> > > >>> change that create time. Linux security model does not allow to change it.
> > > >>>
> > > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> > > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
> > > >>> on Windows systems, then Windows security model should handle it in the
> > > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> > > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
> > > >>>
> > > >>>
> > > >>>
> > > >>> On the other hand, I understand the use case to have two creation times.
> > > >>> One time which would never be changed and could be used for any kind of
> > > >>> atomic / synchronization by userspace application logic (this btime).
> > > >>> And another time for human which can be changed at any time to any value
> > > >>> which user wants (this ptime).
> > > >>>
> > > >>> In any case, I would suggest that filesystem driver would not report to
> > > >>> userspace unsupported values and would not try to invent other values
> > > >>> and lying about them.
> > > >>
> > > >> But all those fs with mutable creation time already report it with STATX_BTIME
> > > >> so what can we do about this?
> > > >
> > > > Well, what I wanted above to point out is that the "mutability" of
> > > > creation time is not feature of filesystem, but in my opinion rather
> > > > property of the security model on the running operating system.
> > > >
> > > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
> > > > In my opinion there is no much difference, both of them has meaning
> > > > "time when was the file created".
> > > >
> > > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
> > > >> those fs could technically return only STATX_PTIME and it should not regress
> > > >> existing programs.
> > > >>
> > > >> But this is still a bit surprising behavior is it not?
> > > >>
> > > >> Thanks,
> > > >> Amir.
> > > >
> > > > I'm not sure what to do with it.
> > > >
> > > > If we allow to change btime of ntfs then for consistency we should also
> > > > allow to change btime of ext4.
> > > >
> > > > Maybe another idea... define new capability which would allow to change
> > > > btime (on any filesystem)? This would at least make the consistency.
> >
> > Pali, I think this is a very bad idea.
>
> Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
>
> > This has nothing to do with capabilities.
> > The Windows and MacOS filesystems have allowed setting their
> > "creation time" forever
>
> FreeBSD for some fs allow it too (see below).
>
> > and for all the other Linux filesystems that had
> > "birth time" it was immutable, so let's not mix filesystem features
> > with capabilities.
>
> I think that it is important to first define behavior and invariants of
> these "btime" and "ptime" kernel properties.
>
> If we want to be consistent then there are two possible options:
>
> 1. If we choose that the STATX_BTIME is immutable then no kernel fs
>    driver should allow to change.
>
> 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
>    then STATX_BTIME is not immutable at all.
>
> These two options cannot be chosen together because option 1 would
> implie that the modifiable "NTFS create time" cannot be reported over
> STATX_BTIME.
>
> We are have currently STATX_BTIME immutable and "NTFS create time"
> reported via STATX_BTIME.
>
> If we want to stay _consistent_ across fs drivers then adding API for
> changing "NTFS create time" would break one of those two things.
>
> In my opinion we should stay consistent across filesystem drivers and
> provide unified behavior of APIs independently of used filesystem.
> Otherwise userspace applications would have to write fs specific code
> for doing their use cases (and we can stay with fs-specific xattrs, no
> need to create unified APIs).
>
> Does it make sense? Or it is still a bad idea to think about it in this way?
>

My "bad idea" comment was only referring to capability.

w.r.t the STATX_BTIME ambiguity there is another option we may want to
consider: Don't publish STATX_PTIME via statx() at all.

One of the reasons that developers have pointed to fileattr as the right API
to host the creation time as well as the DOS attributes is that it has a history
of carrying filesystem specific attributes.

Not every attribute available in lsattr is also available in statx().
If projid is not available in statx() then the settable creation time
doesn't need to be in statx() either.

The file_[sg]etattr() syscalls provides a symmetric API to set/get it.

The same could be true to HIDDEN/ARCHIVE/SYSTEM flags if those
are added to fileattr.

Do we need to stop publishing NTFS creation time in STATX_BTIME?
I think it's too late for that and nobody is going to gain anything
from doing that.

Thanks,
Amir.

Re: [RFC PATCH v3 0/5] add provenance time (ptime)

[Amir Goldstein]

On Tue, Nov 3, 2026 at 12:25 PM koraynilay <koray.fra@gmail.com> wrote:
>
> On Mon Nov 2, 2026 at 3:54 PM CET, Amir Goldstein wrote:
> > On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> wrote:
> >>
> >> 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.
> >
> > FWIW, I agree that given the existing uses of btime and crtime in the
> > kernel and various XXXprogs, using 'ptime' for kernel code is probably
> > the lesser evil.
>
> What do you think about the origiN time (ntime) (Origin: in stat)?
> It would also coincidentally be alphabetically (ntime <-> mtime, n -> m)
> the same as btime <-> ctime (b -> c) ahah.
>

Honestly I don't know.
My new idea is don't publish it in statx() at all.

Thanks,
Amir.

Re: [RFC PATCH v3 1/5] vfs: add provenance time (ptime)

[Amir Goldstein]

On Tue, Nov 3, 2026 at 12:13 PM koraynilay <koray.fra@gmail.com> wrote:
>
> On Mon Nov 2, 2026 at 3:00 PM CET, Amir Goldstein wrote:
> > On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> wrote:
> >>
> >> Add provenance time (ptime), indicating the time when a file or
> >> directory was created. This is user-settable via file_setattr() and
> >> retrievable via statx(2) (using STATX_PTIME) or file_getattr().
> >>
> >> The semantics of when to preserve this new timestamp are the same as
> >> mtime, the idea being that there is a correspondence like this:
> >>
> >> ctime <-> btime
> >> mtime <-> ptime
> >>
> >> so every operation (copying, moving, ...) that currently preserves mtime
> >> should also preserve ptime.
> >>
> >> Furthermore, in order to avoid the legacy FS_IOC_FSSETXATTR accepting
> >> FS_XFLAG_PTIME, add an FS_FILE_ATTR_XFLAGS_MASK mask to support new
> >> xflags, and use it in fileattr_to_file_attr()/file_attr_to_fileattr() to
> >> allow ptime to be used with the file_setattr()/file_getattr() syscalls.
> >>
> >> [ This is a re-implementation of the initial patch[1] by Sean Smith
> >>   <defendthedisabled@gmail.com>, following the advice[2] from Darrick J.
> >>   Wong <djwong@kernel.org> of using file_setattr() instead of updating
> >>   utimensat() ]
> >>
> >> [1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@gmail.com
> >> [2]: https://lore.kernel.org/20260407014129.GC6192@frogsfrogsfrogs
> >>
> >> Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
> >> Signed-off-by: koraynilay <koray.fra@gmail.com>
> >> ---
> >>  fs/file_attr.c            | 33 +++++++++++++++++++++++++++++++--
> >>  fs/stat.c                 |  2 ++
> >>  include/linux/fileattr.h  |  5 +++++
> >>  include/linux/stat.h      |  1 +
> >>  include/uapi/linux/fs.h   |  8 +++++++-
> >>  include/uapi/linux/stat.h |  7 ++++++-
> >>  6 files changed, 52 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/fs/file_attr.c b/fs/file_attr.c
> >> index 833e03810b24..c0645cb22bf3 100644
> >> --- a/fs/file_attr.c
> >> +++ b/fs/file_attr.c
> >> @@ -102,7 +102,7 @@ EXPORT_SYMBOL(vfs_fileattr_get);
> >>  static void fileattr_to_file_attr(const struct file_kattr *fa,
> >>                                   struct file_attr *fattr)
> >>  {
> >> -       __u32 mask = FS_XFLAGS_MASK;
> >> +       __u32 mask = FS_FILE_ATTR_XFLAGS_MASK;
> >>
> >>         memset(fattr, 0, sizeof(struct file_attr));
> >>         fattr->fa_xflags = fa->fsx_xflags & mask;
> >> @@ -110,6 +110,8 @@ static void fileattr_to_file_attr(const struct file_kattr *fa,
> >>         fattr->fa_nextents = fa->fsx_nextents;
> >>         fattr->fa_projid = fa->fsx_projid;
> >>         fattr->fa_cowextsize = fa->fsx_cowextsize;
> >> +       fattr->fa_ptime_sec = fa->fsx_ptime.tv_sec;
> >> +       fattr->fa_ptime_nsec = fa->fsx_ptime.tv_nsec;
> >>  }
> >>
> >>  /**
> >> @@ -141,15 +143,20 @@ EXPORT_SYMBOL(copy_fsxattr_to_user);
> >>  static int file_attr_to_fileattr(const struct file_attr *fattr,
> >>                                  struct file_kattr *fa)
> >>  {
> >> -       __u64 mask = FS_XFLAGS_MASK;
> >> +       __u64 mask = FS_FILE_ATTR_XFLAGS_MASK;
> >
> > That is not the correct way to extend this API.
> > This fixed mask was added as a placeholder for
> > "We intend to add support for more xflags to selective filesystems":
> > https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-2-amir73il@gmail.com/
> >
> > Please see this POC patch for filesystems to publish their supported
> > xflags mask:
> > https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-3-amir73il@gmail.com/
>
> Thanks, I did not think of adding a dynamic mask like that, I will look
> into it and implement it for v4.
>
> > This will allow callers of file_getattr() to know if the filesystem
> > supports ptime
> > without trying to set it and failing.
>
> So after adding fsx_xflags_mask to file_kattr, every filesystem would
> populate fsx_xflags_mask with all the returned (== supported) FS_XFLAG_*
> in their own specific .fileattr_get, correct?

Not all filesystems. Just the ones that wish to extend the constant
legacy FS_XFLAGS_MASK.
So just the ones that you change to support XFLAGS_PTIME

Thanks,
Amir.

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Pali Rohár]

On Tuesday 03 November 2026 16:10:24 Amir Goldstein wrote:
> On Tue, Nov 3, 2026 at 10:49 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
> > > On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
> > > >
> > > > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
> > > > >
> > > > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
> > > > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
> > > > >>>
> > > > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> > > > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> > > > >>>>      if (flags & FS_APPEND_FL)
> > > > >>>>              new_fl |= S_APPEND;
> > > > >>>>
> > > > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> > > > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> > > > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> > > > >>>> +     }
> > > > >>>> +
> > > > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> > > > >>>>
> > > > >>>>      /* Save nodump flag to return in ntfs_getattr. */
> > > > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> > > > >>>>      if (unlikely(is_bad_ni(ni)))
> > > > >>>>              return -EINVAL;
> > > > >>>>
> > > > >>>> -     stat->result_mask |= STATX_BTIME;
> > > > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> > > > >>>>      stat->btime = ni->i_crtime;
> > > > >>>> +     stat->ptime = ni->i_crtime;
> > > > >>>
> > > > >>> For me this patch looks dangerous. Somehow I would expect that the
> > > > >>> "btime" will never change for existing inode.
> > > > >>>
> > > > >>> But because the ptime is mapped to i_crtime and ptime is settable from
> > > > >>> userspace, with this patch it is directly possible to change btime.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> I was thinking more about it... Is not this just misunderstanding of how
> > > > >>> the security model around the times is working on different systems?
> > > > >>> Because on NTFS there is stored just one field which says when the file
> > > > >>> was created. There are not two fields like "time set by user and time
> > > > >>> set by system".
> > > > >>>
> > > > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
> > > > >>> change that create time. Linux security model does not allow to change it.
> > > > >>>
> > > > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> > > > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
> > > > >>> on Windows systems, then Windows security model should handle it in the
> > > > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> > > > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On the other hand, I understand the use case to have two creation times.
> > > > >>> One time which would never be changed and could be used for any kind of
> > > > >>> atomic / synchronization by userspace application logic (this btime).
> > > > >>> And another time for human which can be changed at any time to any value
> > > > >>> which user wants (this ptime).
> > > > >>>
> > > > >>> In any case, I would suggest that filesystem driver would not report to
> > > > >>> userspace unsupported values and would not try to invent other values
> > > > >>> and lying about them.
> > > > >>
> > > > >> But all those fs with mutable creation time already report it with STATX_BTIME
> > > > >> so what can we do about this?
> > > > >
> > > > > Well, what I wanted above to point out is that the "mutability" of
> > > > > creation time is not feature of filesystem, but in my opinion rather
> > > > > property of the security model on the running operating system.
> > > > >
> > > > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
> > > > > In my opinion there is no much difference, both of them has meaning
> > > > > "time when was the file created".
> > > > >
> > > > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
> > > > >> those fs could technically return only STATX_PTIME and it should not regress
> > > > >> existing programs.
> > > > >>
> > > > >> But this is still a bit surprising behavior is it not?
> > > > >>
> > > > >> Thanks,
> > > > >> Amir.
> > > > >
> > > > > I'm not sure what to do with it.
> > > > >
> > > > > If we allow to change btime of ntfs then for consistency we should also
> > > > > allow to change btime of ext4.
> > > > >
> > > > > Maybe another idea... define new capability which would allow to change
> > > > > btime (on any filesystem)? This would at least make the consistency.
> > >
> > > Pali, I think this is a very bad idea.
> >
> > Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
> >
> > > This has nothing to do with capabilities.
> > > The Windows and MacOS filesystems have allowed setting their
> > > "creation time" forever
> >
> > FreeBSD for some fs allow it too (see below).
> >
> > > and for all the other Linux filesystems that had
> > > "birth time" it was immutable, so let's not mix filesystem features
> > > with capabilities.
> >
> > I think that it is important to first define behavior and invariants of
> > these "btime" and "ptime" kernel properties.
> >
> > If we want to be consistent then there are two possible options:
> >
> > 1. If we choose that the STATX_BTIME is immutable then no kernel fs
> >    driver should allow to change.
> >
> > 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
> >    then STATX_BTIME is not immutable at all.
> >
> > These two options cannot be chosen together because option 1 would
> > implie that the modifiable "NTFS create time" cannot be reported over
> > STATX_BTIME.
> >
> > We are have currently STATX_BTIME immutable and "NTFS create time"
> > reported via STATX_BTIME.
> >
> > If we want to stay _consistent_ across fs drivers then adding API for
> > changing "NTFS create time" would break one of those two things.
> >
> > In my opinion we should stay consistent across filesystem drivers and
> > provide unified behavior of APIs independently of used filesystem.
> > Otherwise userspace applications would have to write fs specific code
> > for doing their use cases (and we can stay with fs-specific xattrs, no
> > need to create unified APIs).
> >
> > Does it make sense? Or it is still a bad idea to think about it in this way?
> >
> 
> My "bad idea" comment was only referring to capability.
> 
> w.r.t the STATX_BTIME ambiguity there is another option we may want to
> consider: Don't publish STATX_PTIME via statx() at all.
> 
> One of the reasons that developers have pointed to fileattr as the right API
> to host the creation time as well as the DOS attributes is that it has a history
> of carrying filesystem specific attributes.
> 
> Not every attribute available in lsattr is also available in statx().
> If projid is not available in statx() then the settable creation time
> doesn't need to be in statx() either.
> 
> The file_[sg]etattr() syscalls provides a symmetric API to set/get it.
> 
> The same could be true to HIDDEN/ARCHIVE/SYSTEM flags if those
> are added to fileattr.
> 
> Do we need to stop publishing NTFS creation time in STATX_BTIME?
> I think it's too late for that and nobody is going to gain anything
> from doing that.
> 
> Thanks,
> Amir.

Kernel NTFS driver changed more times, so I would not say that it is too
late to stop publishing NTFS creation time in STATX_BTIME, and start
publishing it in STATX_PTIME.


Anyway, I have another idea (if stopping publishing of NTFS is not possible):
Let fs drivers to fill ptime and btime members only when fs itself
supports particular field (ext4 would fill only btime, nfts would fill
only ptime; btrfs with patch would fill both). For userspace STATX_BTIME
request, VFS will copy ptime to btime if the btime is not provided.
For userspace STATX_PTIME request or STATX_BTIME|STATX_PTIME request,
the VFS will not do this copy. Or We can introduce new flag
STATX_NO_FAKE_BTIME (just random name for now) and this would cause that
the ptime would not be copied to btime (so it would not be needed to
misuse STATX_BTIME|STATX_PTIME). The logic would be unified in VFS
layer, not in the fs drivers.

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 9253 bytes --]

On Tue Nov 3, 2026 at 4:25 PM CET, Pali Rohár wrote:
> On Tuesday 03 November 2026 16:10:24 Amir Goldstein wrote:
>> On Tue, Nov 3, 2026 at 10:49 AM Pali Rohár <pali@kernel.org> wrote:
>> >
>> > On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
>> > > On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
>> > > >
>> > > > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
>> > > > >
>> > > > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
>> > > > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
>> > > > >>>
>> > > > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
>> > > > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
>> > > > >>>>      if (flags & FS_APPEND_FL)
>> > > > >>>>              new_fl |= S_APPEND;
>> > > > >>>>
>> > > > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
>> > > > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
>> > > > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
>> > > > >>>> +     }
>> > > > >>>> +
>> > > > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
>> > > > >>>>
>> > > > >>>>      /* Save nodump flag to return in ntfs_getattr. */
>> > > > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
>> > > > >>>>      if (unlikely(is_bad_ni(ni)))
>> > > > >>>>              return -EINVAL;
>> > > > >>>>
>> > > > >>>> -     stat->result_mask |= STATX_BTIME;
>> > > > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
>> > > > >>>>      stat->btime = ni->i_crtime;
>> > > > >>>> +     stat->ptime = ni->i_crtime;
>> > > > >>>
>> > > > >>> For me this patch looks dangerous. Somehow I would expect that the
>> > > > >>> "btime" will never change for existing inode.
>> > > > >>>
>> > > > >>> But because the ptime is mapped to i_crtime and ptime is settable from
>> > > > >>> userspace, with this patch it is directly possible to change btime.
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> I was thinking more about it... Is not this just misunderstanding of how
>> > > > >>> the security model around the times is working on different systems?
>> > > > >>> Because on NTFS there is stored just one field which says when the file
>> > > > >>> was created. There are not two fields like "time set by user and time
>> > > > >>> set by system".
>> > > > >>>
>> > > > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
>> > > > >>> change that create time. Linux security model does not allow to change it.
>> > > > >>>
>> > > > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
>> > > > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
>> > > > >>> on Windows systems, then Windows security model should handle it in the
>> > > > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
>> > > > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> On the other hand, I understand the use case to have two creation times.
>> > > > >>> One time which would never be changed and could be used for any kind of
>> > > > >>> atomic / synchronization by userspace application logic (this btime).
>> > > > >>> And another time for human which can be changed at any time to any value
>> > > > >>> which user wants (this ptime).
>> > > > >>>
>> > > > >>> In any case, I would suggest that filesystem driver would not report to
>> > > > >>> userspace unsupported values and would not try to invent other values
>> > > > >>> and lying about them.
>> > > > >>
>> > > > >> But all those fs with mutable creation time already report it with STATX_BTIME
>> > > > >> so what can we do about this?
>> > > > >
>> > > > > Well, what I wanted above to point out is that the "mutability" of
>> > > > > creation time is not feature of filesystem, but in my opinion rather
>> > > > > property of the security model on the running operating system.
>> > > > >
>> > > > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
>> > > > > In my opinion there is no much difference, both of them has meaning
>> > > > > "time when was the file created".
>> > > > >
>> > > > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
>> > > > >> those fs could technically return only STATX_PTIME and it should not regress
>> > > > >> existing programs.
>> > > > >>
>> > > > >> But this is still a bit surprising behavior is it not?
>> > > > >>
>> > > > >> Thanks,
>> > > > >> Amir.
>> > > > >
>> > > > > I'm not sure what to do with it.
>> > > > >
>> > > > > If we allow to change btime of ntfs then for consistency we should also
>> > > > > allow to change btime of ext4.
>> > > > >
>> > > > > Maybe another idea... define new capability which would allow to change
>> > > > > btime (on any filesystem)? This would at least make the consistency.
>> > >
>> > > Pali, I think this is a very bad idea.
>> >
>> > Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
>> >
>> > > This has nothing to do with capabilities.
>> > > The Windows and MacOS filesystems have allowed setting their
>> > > "creation time" forever
>> >
>> > FreeBSD for some fs allow it too (see below).
>> >
>> > > and for all the other Linux filesystems that had
>> > > "birth time" it was immutable, so let's not mix filesystem features
>> > > with capabilities.
>> >
>> > I think that it is important to first define behavior and invariants of
>> > these "btime" and "ptime" kernel properties.
>> >
>> > If we want to be consistent then there are two possible options:
>> >
>> > 1. If we choose that the STATX_BTIME is immutable then no kernel fs
>> >    driver should allow to change.
>> >
>> > 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
>> >    then STATX_BTIME is not immutable at all.
>> >
>> > These two options cannot be chosen together because option 1 would
>> > implie that the modifiable "NTFS create time" cannot be reported over
>> > STATX_BTIME.
>> >
>> > We are have currently STATX_BTIME immutable and "NTFS create time"
>> > reported via STATX_BTIME.
>> >
>> > If we want to stay _consistent_ across fs drivers then adding API for
>> > changing "NTFS create time" would break one of those two things.
>> >
>> > In my opinion we should stay consistent across filesystem drivers and
>> > provide unified behavior of APIs independently of used filesystem.
>> > Otherwise userspace applications would have to write fs specific code
>> > for doing their use cases (and we can stay with fs-specific xattrs, no
>> > need to create unified APIs).
>> >
>> > Does it make sense? Or it is still a bad idea to think about it in this way?
>> >
>> 
>> My "bad idea" comment was only referring to capability.
>> 
>> w.r.t the STATX_BTIME ambiguity there is another option we may want to
>> consider: Don't publish STATX_PTIME via statx() at all.
>> 
>> One of the reasons that developers have pointed to fileattr as the right API
>> to host the creation time as well as the DOS attributes is that it has a history
>> of carrying filesystem specific attributes.
>> 
>> Not every attribute available in lsattr is also available in statx().
>> If projid is not available in statx() then the settable creation time
>> doesn't need to be in statx() either.
>> 
>> The file_[sg]etattr() syscalls provides a symmetric API to set/get it.
>> 
>> The same could be true to HIDDEN/ARCHIVE/SYSTEM flags if those
>> are added to fileattr.
>> 
>> Do we need to stop publishing NTFS creation time in STATX_BTIME?
>> I think it's too late for that and nobody is going to gain anything
>> from doing that.
>> 
>> Thanks,
>> Amir.
>
> Kernel NTFS driver changed more times, so I would not say that it is too
> late to stop publishing NTFS creation time in STATX_BTIME, and start
> publishing it in STATX_PTIME.
>
>
> Anyway, I have another idea (if stopping publishing of NTFS is not possible):
> Let fs drivers to fill ptime and btime members only when fs itself
> supports particular field (ext4 would fill only btime, nfts would fill
> only ptime; btrfs with patch would fill both). For userspace STATX_BTIME
> request, VFS will copy ptime to btime if the btime is not provided.
> For userspace STATX_PTIME request or STATX_BTIME|STATX_PTIME request,
> the VFS will not do this copy. Or We can introduce new flag
> STATX_NO_FAKE_BTIME (just random name for now) and this would cause that
> the ptime would not be copied to btime (so it would not be needed to
> misuse STATX_BTIME|STATX_PTIME). The logic would be unified in VFS
> layer, not in the fs drivers.

I feel like this would be a bit of an over-complication/not clear
enough, as we would merge a lot more of the meaning of btime and ptime,
while you would never return mtime when userspace asks for  ctime (I
think?).

But maybe it could make sense as a compromise to not break userspace too
much.


Best,
koraynilay

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 8299 bytes --]

On Tue Nov 3, 2026 at 4:10 PM CET, Amir Goldstein wrote:
> On Tue, Nov 3, 2026 at 10:49 AM Pali Rohár <pali@kernel.org> wrote:
>>
>> On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
>> > On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
>> > >
>> > > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
>> > > >
>> > > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
>> > > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
>> > > >>>
>> > > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
>> > > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
>> > > >>>>      if (flags & FS_APPEND_FL)
>> > > >>>>              new_fl |= S_APPEND;
>> > > >>>>
>> > > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
>> > > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
>> > > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
>> > > >>>> +     }
>> > > >>>> +
>> > > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
>> > > >>>>
>> > > >>>>      /* Save nodump flag to return in ntfs_getattr. */
>> > > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
>> > > >>>>      if (unlikely(is_bad_ni(ni)))
>> > > >>>>              return -EINVAL;
>> > > >>>>
>> > > >>>> -     stat->result_mask |= STATX_BTIME;
>> > > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
>> > > >>>>      stat->btime = ni->i_crtime;
>> > > >>>> +     stat->ptime = ni->i_crtime;
>> > > >>>
>> > > >>> For me this patch looks dangerous. Somehow I would expect that the
>> > > >>> "btime" will never change for existing inode.
>> > > >>>
>> > > >>> But because the ptime is mapped to i_crtime and ptime is settable from
>> > > >>> userspace, with this patch it is directly possible to change btime.
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>> I was thinking more about it... Is not this just misunderstanding of how
>> > > >>> the security model around the times is working on different systems?
>> > > >>> Because on NTFS there is stored just one field which says when the file
>> > > >>> was created. There are not two fields like "time set by user and time
>> > > >>> set by system".
>> > > >>>
>> > > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
>> > > >>> change that create time. Linux security model does not allow to change it.
>> > > >>>
>> > > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
>> > > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
>> > > >>> on Windows systems, then Windows security model should handle it in the
>> > > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
>> > > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>> On the other hand, I understand the use case to have two creation times.
>> > > >>> One time which would never be changed and could be used for any kind of
>> > > >>> atomic / synchronization by userspace application logic (this btime).
>> > > >>> And another time for human which can be changed at any time to any value
>> > > >>> which user wants (this ptime).
>> > > >>>
>> > > >>> In any case, I would suggest that filesystem driver would not report to
>> > > >>> userspace unsupported values and would not try to invent other values
>> > > >>> and lying about them.
>> > > >>
>> > > >> But all those fs with mutable creation time already report it with STATX_BTIME
>> > > >> so what can we do about this?
>> > > >
>> > > > Well, what I wanted above to point out is that the "mutability" of
>> > > > creation time is not feature of filesystem, but in my opinion rather
>> > > > property of the security model on the running operating system.
>> > > >
>> > > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
>> > > > In my opinion there is no much difference, both of them has meaning
>> > > > "time when was the file created".
>> > > >
>> > > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
>> > > >> those fs could technically return only STATX_PTIME and it should not regress
>> > > >> existing programs.
>> > > >>
>> > > >> But this is still a bit surprising behavior is it not?
>> > > >>
>> > > >> Thanks,
>> > > >> Amir.
>> > > >
>> > > > I'm not sure what to do with it.
>> > > >
>> > > > If we allow to change btime of ntfs then for consistency we should also
>> > > > allow to change btime of ext4.
>> > > >
>> > > > Maybe another idea... define new capability which would allow to change
>> > > > btime (on any filesystem)? This would at least make the consistency.
>> >
>> > Pali, I think this is a very bad idea.
>>
>> Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
>>
>> > This has nothing to do with capabilities.
>> > The Windows and MacOS filesystems have allowed setting their
>> > "creation time" forever
>>
>> FreeBSD for some fs allow it too (see below).
>>
>> > and for all the other Linux filesystems that had
>> > "birth time" it was immutable, so let's not mix filesystem features
>> > with capabilities.
>>
>> I think that it is important to first define behavior and invariants of
>> these "btime" and "ptime" kernel properties.
>>
>> If we want to be consistent then there are two possible options:
>>
>> 1. If we choose that the STATX_BTIME is immutable then no kernel fs
>>    driver should allow to change.
>>
>> 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
>>    then STATX_BTIME is not immutable at all.
>>
>> These two options cannot be chosen together because option 1 would
>> implie that the modifiable "NTFS create time" cannot be reported over
>> STATX_BTIME.
>>
>> We are have currently STATX_BTIME immutable and "NTFS create time"
>> reported via STATX_BTIME.
>>
>> If we want to stay _consistent_ across fs drivers then adding API for
>> changing "NTFS create time" would break one of those two things.
>>
>> In my opinion we should stay consistent across filesystem drivers and
>> provide unified behavior of APIs independently of used filesystem.
>> Otherwise userspace applications would have to write fs specific code
>> for doing their use cases (and we can stay with fs-specific xattrs, no
>> need to create unified APIs).
>>
>> Does it make sense? Or it is still a bad idea to think about it in this way?
>>
>
> My "bad idea" comment was only referring to capability.
>
> w.r.t the STATX_BTIME ambiguity there is another option we may want to
> consider: Don't publish STATX_PTIME via statx() at all.
>
> One of the reasons that developers have pointed to fileattr as the right API
> to host the creation time as well as the DOS attributes is that it has a history
> of carrying filesystem specific attributes.
>
> Not every attribute available in lsattr is also available in statx().
> If projid is not available in statx() then the settable creation time
> doesn't need to be in statx() either.
>
> The file_[sg]etattr() syscalls provides a symmetric API to set/get it.

btime currently is also a fliesystem specific implementation tho, and
there was already a transition from stat to statx when btime was added,
so I think ptime should be included in statx, especially since it should
be treated as one of the standard timestamps from now on (or at least,
that's what I hope to achieve eventually).
The only difference to the currently standard timestamps would be that
a/mtime are managed by utimensat, ctime/btime by the filesystems
themselves (as they're more "internal" and less "user-facing") and ptime
would be managed by file_[gs]etattr() (since changing utimensat wouldn't
make sense as said in the april thread).

Thanks,
koraynilay

> The same could be true to HIDDEN/ARCHIVE/SYSTEM flags if those
> are added to fileattr.
>
> Do we need to stop publishing NTFS creation time in STATX_BTIME?
> I think it's too late for that and nobody is going to gain anything
> from doing that.
>
> Thanks,
> Amir.



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH v3 0/5] add provenance time (ptime)

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]

On Tue Nov 3, 2026 at 4:12 PM CET, Amir Goldstein wrote:
> On Tue, Nov 3, 2026 at 12:25 PM koraynilay <koray.fra@gmail.com> wrote:
>>
>> On Mon Nov 2, 2026 at 3:54 PM CET, Amir Goldstein wrote:
>> > On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> wrote:
>> >>
>> >> 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.
>> >
>> > FWIW, I agree that given the existing uses of btime and crtime in the
>> > kernel and various XXXprogs, using 'ptime' for kernel code is probably
>> > the lesser evil.
>>
>> What do you think about the origiN time (ntime) (Origin: in stat)?
>> It would also coincidentally be alphabetically (ntime <-> mtime, n -> m)
>> the same as btime <-> ctime (b -> c) ahah.
>>
>
> Honestly I don't know.
> My new idea is don't publish it in statx() at all.

Well I was more talking about the actual variable names in all patches
ahah.

Thanks,
koraynilay

> Thanks,
> Amir.



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH v3 1/5] vfs: add provenance time (ptime)

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 4796 bytes --]

On Tue Nov 3, 2026 at 4:14 PM CET, Amir Goldstein wrote:
> On Tue, Nov 3, 2026 at 12:13 PM koraynilay <koray.fra@gmail.com> wrote:
>>
>> On Mon Nov 2, 2026 at 3:00 PM CET, Amir Goldstein wrote:
>> > On Sun, Nov 1, 2026 at 2:57 AM koraynilay <koray.fra@gmail.com> wrote:
>> >>
>> >> Add provenance time (ptime), indicating the time when a file or
>> >> directory was created. This is user-settable via file_setattr() and
>> >> retrievable via statx(2) (using STATX_PTIME) or file_getattr().
>> >>
>> >> The semantics of when to preserve this new timestamp are the same as
>> >> mtime, the idea being that there is a correspondence like this:
>> >>
>> >> ctime <-> btime
>> >> mtime <-> ptime
>> >>
>> >> so every operation (copying, moving, ...) that currently preserves mtime
>> >> should also preserve ptime.
>> >>
>> >> Furthermore, in order to avoid the legacy FS_IOC_FSSETXATTR accepting
>> >> FS_XFLAG_PTIME, add an FS_FILE_ATTR_XFLAGS_MASK mask to support new
>> >> xflags, and use it in fileattr_to_file_attr()/file_attr_to_fileattr() to
>> >> allow ptime to be used with the file_setattr()/file_getattr() syscalls.
>> >>
>> >> [ This is a re-implementation of the initial patch[1] by Sean Smith
>> >>   <defendthedisabled@gmail.com>, following the advice[2] from Darrick J.
>> >>   Wong <djwong@kernel.org> of using file_setattr() instead of updating
>> >>   utimensat() ]
>> >>
>> >> [1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@gmail.com
>> >> [2]: https://lore.kernel.org/20260407014129.GC6192@frogsfrogsfrogs
>> >>
>> >> Assisted-by: Gemini:3.8-flash-high antigravity-cli-1.4.7
>> >> Signed-off-by: koraynilay <koray.fra@gmail.com>
>> >> ---
>> >>  fs/file_attr.c            | 33 +++++++++++++++++++++++++++++++--
>> >>  fs/stat.c                 |  2 ++
>> >>  include/linux/fileattr.h  |  5 +++++
>> >>  include/linux/stat.h      |  1 +
>> >>  include/uapi/linux/fs.h   |  8 +++++++-
>> >>  include/uapi/linux/stat.h |  7 ++++++-
>> >>  6 files changed, 52 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/fs/file_attr.c b/fs/file_attr.c
>> >> index 833e03810b24..c0645cb22bf3 100644
>> >> --- a/fs/file_attr.c
>> >> +++ b/fs/file_attr.c
>> >> @@ -102,7 +102,7 @@ EXPORT_SYMBOL(vfs_fileattr_get);
>> >>  static void fileattr_to_file_attr(const struct file_kattr *fa,
>> >>                                   struct file_attr *fattr)
>> >>  {
>> >> -       __u32 mask = FS_XFLAGS_MASK;
>> >> +       __u32 mask = FS_FILE_ATTR_XFLAGS_MASK;
>> >>
>> >>         memset(fattr, 0, sizeof(struct file_attr));
>> >>         fattr->fa_xflags = fa->fsx_xflags & mask;
>> >> @@ -110,6 +110,8 @@ static void fileattr_to_file_attr(const struct file_kattr *fa,
>> >>         fattr->fa_nextents = fa->fsx_nextents;
>> >>         fattr->fa_projid = fa->fsx_projid;
>> >>         fattr->fa_cowextsize = fa->fsx_cowextsize;
>> >> +       fattr->fa_ptime_sec = fa->fsx_ptime.tv_sec;
>> >> +       fattr->fa_ptime_nsec = fa->fsx_ptime.tv_nsec;
>> >>  }
>> >>
>> >>  /**
>> >> @@ -141,15 +143,20 @@ EXPORT_SYMBOL(copy_fsxattr_to_user);
>> >>  static int file_attr_to_fileattr(const struct file_attr *fattr,
>> >>                                  struct file_kattr *fa)
>> >>  {
>> >> -       __u64 mask = FS_XFLAGS_MASK;
>> >> +       __u64 mask = FS_FILE_ATTR_XFLAGS_MASK;
>> >
>> > That is not the correct way to extend this API.
>> > This fixed mask was added as a placeholder for
>> > "We intend to add support for more xflags to selective filesystems":
>> > https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-2-amir73il@gmail.com/
>> >
>> > Please see this POC patch for filesystems to publish their supported
>> > xflags mask:
>> > https://lore.kernel.org/linux-fsdevel/20250329143312.1350603-3-amir73il@gmail.com/
>>
>> Thanks, I did not think of adding a dynamic mask like that, I will look
>> into it and implement it for v4.
>>
>> > This will allow callers of file_getattr() to know if the filesystem
>> > supports ptime
>> > without trying to set it and failing.
>>
>> So after adding fsx_xflags_mask to file_kattr, every filesystem would
>> populate fsx_xflags_mask with all the returned (== supported) FS_XFLAG_*
>> in their own specific .fileattr_get, correct?
>
> Not all filesystems. Just the ones that wish to extend the constant
> legacy FS_XFLAGS_MASK.
> So just the ones that you change to support XFLAGS_PTIME

Ah ok yeah that makes more sense, so like the fileattr_has_fsx_mask()
(that checks if fa has fsx, ignoring the suppored/allowed ones specified
as second arg) that I added, but in the opposite way: "I advertise only
the extra fsx (so only 0 or FS_XFLAG_PTIME rn) that I support".

Thanks,
koraynilay

> Thanks,
> Amir.



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Pali Rohár]

On Tuesday 03 November 2026 18:07:43 koraynilay wrote:
> On Tue Nov 3, 2026 at 4:25 PM CET, Pali Rohár wrote:
> > On Tuesday 03 November 2026 16:10:24 Amir Goldstein wrote:
> >> On Tue, Nov 3, 2026 at 10:49 AM Pali Rohár <pali@kernel.org> wrote:
> >> >
> >> > On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
> >> > > On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
> >> > > >
> >> > > > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
> >> > > > >
> >> > > > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
> >> > > > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
> >> > > > >>>
> >> > > > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> >> > > > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> >> > > > >>>>      if (flags & FS_APPEND_FL)
> >> > > > >>>>              new_fl |= S_APPEND;
> >> > > > >>>>
> >> > > > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> >> > > > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> >> > > > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> >> > > > >>>> +     }
> >> > > > >>>> +
> >> > > > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> >> > > > >>>>
> >> > > > >>>>      /* Save nodump flag to return in ntfs_getattr. */
> >> > > > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> >> > > > >>>>      if (unlikely(is_bad_ni(ni)))
> >> > > > >>>>              return -EINVAL;
> >> > > > >>>>
> >> > > > >>>> -     stat->result_mask |= STATX_BTIME;
> >> > > > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> >> > > > >>>>      stat->btime = ni->i_crtime;
> >> > > > >>>> +     stat->ptime = ni->i_crtime;
> >> > > > >>>
> >> > > > >>> For me this patch looks dangerous. Somehow I would expect that the
> >> > > > >>> "btime" will never change for existing inode.
> >> > > > >>>
> >> > > > >>> But because the ptime is mapped to i_crtime and ptime is settable from
> >> > > > >>> userspace, with this patch it is directly possible to change btime.
> >> > > > >>>
> >> > > > >>>
> >> > > > >>>
> >> > > > >>> I was thinking more about it... Is not this just misunderstanding of how
> >> > > > >>> the security model around the times is working on different systems?
> >> > > > >>> Because on NTFS there is stored just one field which says when the file
> >> > > > >>> was created. There are not two fields like "time set by user and time
> >> > > > >>> set by system".
> >> > > > >>>
> >> > > > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
> >> > > > >>> change that create time. Linux security model does not allow to change it.
> >> > > > >>>
> >> > > > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> >> > > > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
> >> > > > >>> on Windows systems, then Windows security model should handle it in the
> >> > > > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> >> > > > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
> >> > > > >>>
> >> > > > >>>
> >> > > > >>>
> >> > > > >>> On the other hand, I understand the use case to have two creation times.
> >> > > > >>> One time which would never be changed and could be used for any kind of
> >> > > > >>> atomic / synchronization by userspace application logic (this btime).
> >> > > > >>> And another time for human which can be changed at any time to any value
> >> > > > >>> which user wants (this ptime).
> >> > > > >>>
> >> > > > >>> In any case, I would suggest that filesystem driver would not report to
> >> > > > >>> userspace unsupported values and would not try to invent other values
> >> > > > >>> and lying about them.
> >> > > > >>
> >> > > > >> But all those fs with mutable creation time already report it with STATX_BTIME
> >> > > > >> so what can we do about this?
> >> > > > >
> >> > > > > Well, what I wanted above to point out is that the "mutability" of
> >> > > > > creation time is not feature of filesystem, but in my opinion rather
> >> > > > > property of the security model on the running operating system.
> >> > > > >
> >> > > > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
> >> > > > > In my opinion there is no much difference, both of them has meaning
> >> > > > > "time when was the file created".
> >> > > > >
> >> > > > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
> >> > > > >> those fs could technically return only STATX_PTIME and it should not regress
> >> > > > >> existing programs.
> >> > > > >>
> >> > > > >> But this is still a bit surprising behavior is it not?
> >> > > > >>
> >> > > > >> Thanks,
> >> > > > >> Amir.
> >> > > > >
> >> > > > > I'm not sure what to do with it.
> >> > > > >
> >> > > > > If we allow to change btime of ntfs then for consistency we should also
> >> > > > > allow to change btime of ext4.
> >> > > > >
> >> > > > > Maybe another idea... define new capability which would allow to change
> >> > > > > btime (on any filesystem)? This would at least make the consistency.
> >> > >
> >> > > Pali, I think this is a very bad idea.
> >> >
> >> > Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
> >> >
> >> > > This has nothing to do with capabilities.
> >> > > The Windows and MacOS filesystems have allowed setting their
> >> > > "creation time" forever
> >> >
> >> > FreeBSD for some fs allow it too (see below).
> >> >
> >> > > and for all the other Linux filesystems that had
> >> > > "birth time" it was immutable, so let's not mix filesystem features
> >> > > with capabilities.
> >> >
> >> > I think that it is important to first define behavior and invariants of
> >> > these "btime" and "ptime" kernel properties.
> >> >
> >> > If we want to be consistent then there are two possible options:
> >> >
> >> > 1. If we choose that the STATX_BTIME is immutable then no kernel fs
> >> >    driver should allow to change.
> >> >
> >> > 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
> >> >    then STATX_BTIME is not immutable at all.
> >> >
> >> > These two options cannot be chosen together because option 1 would
> >> > implie that the modifiable "NTFS create time" cannot be reported over
> >> > STATX_BTIME.
> >> >
> >> > We are have currently STATX_BTIME immutable and "NTFS create time"
> >> > reported via STATX_BTIME.
> >> >
> >> > If we want to stay _consistent_ across fs drivers then adding API for
> >> > changing "NTFS create time" would break one of those two things.
> >> >
> >> > In my opinion we should stay consistent across filesystem drivers and
> >> > provide unified behavior of APIs independently of used filesystem.
> >> > Otherwise userspace applications would have to write fs specific code
> >> > for doing their use cases (and we can stay with fs-specific xattrs, no
> >> > need to create unified APIs).
> >> >
> >> > Does it make sense? Or it is still a bad idea to think about it in this way?
> >> >
> >> 
> >> My "bad idea" comment was only referring to capability.
> >> 
> >> w.r.t the STATX_BTIME ambiguity there is another option we may want to
> >> consider: Don't publish STATX_PTIME via statx() at all.
> >> 
> >> One of the reasons that developers have pointed to fileattr as the right API
> >> to host the creation time as well as the DOS attributes is that it has a history
> >> of carrying filesystem specific attributes.
> >> 
> >> Not every attribute available in lsattr is also available in statx().
> >> If projid is not available in statx() then the settable creation time
> >> doesn't need to be in statx() either.
> >> 
> >> The file_[sg]etattr() syscalls provides a symmetric API to set/get it.
> >> 
> >> The same could be true to HIDDEN/ARCHIVE/SYSTEM flags if those
> >> are added to fileattr.
> >> 
> >> Do we need to stop publishing NTFS creation time in STATX_BTIME?
> >> I think it's too late for that and nobody is going to gain anything
> >> from doing that.
> >> 
> >> Thanks,
> >> Amir.
> >
> > Kernel NTFS driver changed more times, so I would not say that it is too
> > late to stop publishing NTFS creation time in STATX_BTIME, and start
> > publishing it in STATX_PTIME.
> >
> >
> > Anyway, I have another idea (if stopping publishing of NTFS is not possible):
> > Let fs drivers to fill ptime and btime members only when fs itself
> > supports particular field (ext4 would fill only btime, nfts would fill
> > only ptime; btrfs with patch would fill both). For userspace STATX_BTIME
> > request, VFS will copy ptime to btime if the btime is not provided.
> > For userspace STATX_PTIME request or STATX_BTIME|STATX_PTIME request,
> > the VFS will not do this copy. Or We can introduce new flag
> > STATX_NO_FAKE_BTIME (just random name for now) and this would cause that
> > the ptime would not be copied to btime (so it would not be needed to
> > misuse STATX_BTIME|STATX_PTIME). The logic would be unified in VFS
> > layer, not in the fs drivers.
> 
> I feel like this would be a bit of an over-complication/not clear
> enough, as we would merge a lot more of the meaning of btime and ptime,

Yes, this would need a very clear and unambiguous documentation because
otherwise it would not be clear for developers how to use such API.

> while you would never return mtime when userspace asks for  ctime (I
> think?).

Yes, this is another argument why to rather stop publishing NTFS
creation time in STATX_BTIME (of course if it is possible).

> But maybe it could make sense as a compromise to not break userspace too
> much.
> 
> 
> Best,
> koraynilay

Every compromise has something good and something bad.
I'm just trying to brainstorm ideas and possible solutions.

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[Pali Rohár]

On Tuesday 03 November 2026 18:20:24 koraynilay wrote:
> On Tue Nov 3, 2026 at 4:10 PM CET, Amir Goldstein wrote:
> > On Tue, Nov 3, 2026 at 10:49 AM Pali Rohár <pali@kernel.org> wrote:
> >>
> >> On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
> >> > On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
> >> > >
> >> > > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
> >> > > >
> >> > > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
> >> > > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
> >> > > >>>
> >> > > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> >> > > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
> >> > > >>>>      if (flags & FS_APPEND_FL)
> >> > > >>>>              new_fl |= S_APPEND;
> >> > > >>>>
> >> > > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> >> > > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> >> > > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> >> > > >>>> +     }
> >> > > >>>> +
> >> > > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
> >> > > >>>>
> >> > > >>>>      /* Save nodump flag to return in ntfs_getattr. */
> >> > > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
> >> > > >>>>      if (unlikely(is_bad_ni(ni)))
> >> > > >>>>              return -EINVAL;
> >> > > >>>>
> >> > > >>>> -     stat->result_mask |= STATX_BTIME;
> >> > > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
> >> > > >>>>      stat->btime = ni->i_crtime;
> >> > > >>>> +     stat->ptime = ni->i_crtime;
> >> > > >>>
> >> > > >>> For me this patch looks dangerous. Somehow I would expect that the
> >> > > >>> "btime" will never change for existing inode.
> >> > > >>>
> >> > > >>> But because the ptime is mapped to i_crtime and ptime is settable from
> >> > > >>> userspace, with this patch it is directly possible to change btime.
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >>> I was thinking more about it... Is not this just misunderstanding of how
> >> > > >>> the security model around the times is working on different systems?
> >> > > >>> Because on NTFS there is stored just one field which says when the file
> >> > > >>> was created. There are not two fields like "time set by user and time
> >> > > >>> set by system".
> >> > > >>>
> >> > > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
> >> > > >>> change that create time. Linux security model does not allow to change it.
> >> > > >>>
> >> > > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
> >> > > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
> >> > > >>> on Windows systems, then Windows security model should handle it in the
> >> > > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
> >> > > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >>> On the other hand, I understand the use case to have two creation times.
> >> > > >>> One time which would never be changed and could be used for any kind of
> >> > > >>> atomic / synchronization by userspace application logic (this btime).
> >> > > >>> And another time for human which can be changed at any time to any value
> >> > > >>> which user wants (this ptime).
> >> > > >>>
> >> > > >>> In any case, I would suggest that filesystem driver would not report to
> >> > > >>> userspace unsupported values and would not try to invent other values
> >> > > >>> and lying about them.
> >> > > >>
> >> > > >> But all those fs with mutable creation time already report it with STATX_BTIME
> >> > > >> so what can we do about this?
> >> > > >
> >> > > > Well, what I wanted above to point out is that the "mutability" of
> >> > > > creation time is not feature of filesystem, but in my opinion rather
> >> > > > property of the security model on the running operating system.
> >> > > >
> >> > > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
> >> > > > In my opinion there is no much difference, both of them has meaning
> >> > > > "time when was the file created".
> >> > > >
> >> > > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
> >> > > >> those fs could technically return only STATX_PTIME and it should not regress
> >> > > >> existing programs.
> >> > > >>
> >> > > >> But this is still a bit surprising behavior is it not?
> >> > > >>
> >> > > >> Thanks,
> >> > > >> Amir.
> >> > > >
> >> > > > I'm not sure what to do with it.
> >> > > >
> >> > > > If we allow to change btime of ntfs then for consistency we should also
> >> > > > allow to change btime of ext4.
> >> > > >
> >> > > > Maybe another idea... define new capability which would allow to change
> >> > > > btime (on any filesystem)? This would at least make the consistency.
> >> >
> >> > Pali, I think this is a very bad idea.
> >>
> >> Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
> >>
> >> > This has nothing to do with capabilities.
> >> > The Windows and MacOS filesystems have allowed setting their
> >> > "creation time" forever
> >>
> >> FreeBSD for some fs allow it too (see below).
> >>
> >> > and for all the other Linux filesystems that had
> >> > "birth time" it was immutable, so let's not mix filesystem features
> >> > with capabilities.
> >>
> >> I think that it is important to first define behavior and invariants of
> >> these "btime" and "ptime" kernel properties.
> >>
> >> If we want to be consistent then there are two possible options:
> >>
> >> 1. If we choose that the STATX_BTIME is immutable then no kernel fs
> >>    driver should allow to change.
> >>
> >> 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
> >>    then STATX_BTIME is not immutable at all.
> >>
> >> These two options cannot be chosen together because option 1 would
> >> implie that the modifiable "NTFS create time" cannot be reported over
> >> STATX_BTIME.
> >>
> >> We are have currently STATX_BTIME immutable and "NTFS create time"
> >> reported via STATX_BTIME.
> >>
> >> If we want to stay _consistent_ across fs drivers then adding API for
> >> changing "NTFS create time" would break one of those two things.
> >>
> >> In my opinion we should stay consistent across filesystem drivers and
> >> provide unified behavior of APIs independently of used filesystem.
> >> Otherwise userspace applications would have to write fs specific code
> >> for doing their use cases (and we can stay with fs-specific xattrs, no
> >> need to create unified APIs).
> >>
> >> Does it make sense? Or it is still a bad idea to think about it in this way?
> >>
> >
> > My "bad idea" comment was only referring to capability.
> >
> > w.r.t the STATX_BTIME ambiguity there is another option we may want to
> > consider: Don't publish STATX_PTIME via statx() at all.
> >
> > One of the reasons that developers have pointed to fileattr as the right API
> > to host the creation time as well as the DOS attributes is that it has a history
> > of carrying filesystem specific attributes.
> >
> > Not every attribute available in lsattr is also available in statx().
> > If projid is not available in statx() then the settable creation time
> > doesn't need to be in statx() either.
> >
> > The file_[sg]etattr() syscalls provides a symmetric API to set/get it.
> 
> btime currently is also a fliesystem specific implementation tho, and
> there was already a transition from stat to statx when btime was added,
> so I think ptime should be included in statx, especially since it should
> be treated as one of the standard timestamps from now on (or at least,
> that's what I hope to achieve eventually).
> The only difference to the currently standard timestamps would be that
> a/mtime are managed by utimensat, ctime/btime by the filesystems
> themselves (as they're more "internal" and less "user-facing") and ptime
> would be managed by file_[gs]etattr() (since changing utimensat wouldn't
> make sense as said in the april thread).

Not related to these changes, but I think it would make sense to adjust
also utimensat man page documentation and mention there what kind of
syscall/function will be used for changing ptime. From my experience,
such cross reference can help developers. Also the fact is that FreeBSD
changes birth time via utimes syscall could mean that developers could
look for similar Linux functionality in linux utime* manpages.

> Thanks,
> koraynilay
> 
> > The same could be true to HIDDEN/ARCHIVE/SYSTEM flags if those
> > are added to fileattr.
> >
> > Do we need to stop publishing NTFS creation time in STATX_BTIME?
> > I think it's too late for that and nobody is going to gain anything
> > from doing that.
> >
> > Thanks,
> > Amir.
> 
> 

Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

[koraynilay]

[-- Attachment #1: Type: text/plain, Size: 9558 bytes --]

On Tue Nov 3, 2026 at 6:32 PM CET, Pali Rohár wrote:
> On Tuesday 03 November 2026 18:20:24 koraynilay wrote:
>> On Tue Nov 3, 2026 at 4:10 PM CET, Amir Goldstein wrote:
>> > On Tue, Nov 3, 2026 at 10:49 AM Pali Rohár <pali@kernel.org> wrote:
>> >>
>> >> On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
>> >> > On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@dilger.ca> wrote:
>> >> > >
>> >> > > On Nov 2, 2026, at 09:38, Pali Rohár <pali@kernel.org> wrote:
>> >> > > >
>> >> > > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote:
>> >> > > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár <pali@kernel.org> wrote:
>> >> > > >>>
>> >> > > >>> On Sunday 01 November 2026 02:55:49 koraynilay wrote:
>> >> > > >>>> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
>> >> > > >>>>      if (flags & FS_APPEND_FL)
>> >> > > >>>>              new_fl |= S_APPEND;
>> >> > > >>>>
>> >> > > >>>> +     if (fa->fsx_xflags & FS_XFLAG_PTIME) {
>> >> > > >>>> +             ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
>> >> > > >>>> +             ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
>> >> > > >>>> +     }
>> >> > > >>>> +
>> >> > > >>>>      inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
>> >> > > >>>>
>> >> > > >>>>      /* Save nodump flag to return in ntfs_getattr. */
>> >> > > >>>> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
>> >> > > >>>>      if (unlikely(is_bad_ni(ni)))
>> >> > > >>>>              return -EINVAL;
>> >> > > >>>>
>> >> > > >>>> -     stat->result_mask |= STATX_BTIME;
>> >> > > >>>> +     stat->result_mask |= (STATX_BTIME | STATX_PTIME);
>> >> > > >>>>      stat->btime = ni->i_crtime;
>> >> > > >>>> +     stat->ptime = ni->i_crtime;
>> >> > > >>>
>> >> > > >>> For me this patch looks dangerous. Somehow I would expect that the
>> >> > > >>> "btime" will never change for existing inode.
>> >> > > >>>
>> >> > > >>> But because the ptime is mapped to i_crtime and ptime is settable from
>> >> > > >>> userspace, with this patch it is directly possible to change btime.
>> >> > > >>>
>> >> > > >>>
>> >> > > >>>
>> >> > > >>> I was thinking more about it... Is not this just misunderstanding of how
>> >> > > >>> the security model around the times is working on different systems?
>> >> > > >>> Because on NTFS there is stored just one field which says when the file
>> >> > > >>> was created. There are not two fields like "time set by user and time
>> >> > > >>> set by system".
>> >> > > >>>
>> >> > > >>> Windows security model allows anybody with WRITE_ATTRIBUTES access to
>> >> > > >>> change that create time. Linux security model does not allow to change it.
>> >> > > >>>
>> >> > > >>> NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
>> >> > > >>> In my opinion if the ext4 or btrfs filesystem is correctly implemented
>> >> > > >>> on Windows systems, then Windows security model should handle it in the
>> >> > > >>> same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
>> >> > > >>> access, then Windows should allow to change also btime on ext4 or btrfs.
>> >> > > >>>
>> >> > > >>>
>> >> > > >>>
>> >> > > >>> On the other hand, I understand the use case to have two creation times.
>> >> > > >>> One time which would never be changed and could be used for any kind of
>> >> > > >>> atomic / synchronization by userspace application logic (this btime).
>> >> > > >>> And another time for human which can be changed at any time to any value
>> >> > > >>> which user wants (this ptime).
>> >> > > >>>
>> >> > > >>> In any case, I would suggest that filesystem driver would not report to
>> >> > > >>> userspace unsupported values and would not try to invent other values
>> >> > > >>> and lying about them.
>> >> > > >>
>> >> > > >> But all those fs with mutable creation time already report it with STATX_BTIME
>> >> > > >> so what can we do about this?
>> >> > > >
>> >> > > > Well, what I wanted above to point out is that the "mutability" of
>> >> > > > creation time is not feature of filesystem, but in my opinion rather
>> >> > > > property of the security model on the running operating system.
>> >> > > >
>> >> > > > Maybe better question is: how ext4 btimes differs from the ntfs btime?
>> >> > > > In my opinion there is no much difference, both of them has meaning
>> >> > > > "time when was the file created".
>> >> > > >
>> >> > > >> If userspace requests both STATX_BTIME|STATX_PTIME in mask arg,
>> >> > > >> those fs could technically return only STATX_PTIME and it should not regress
>> >> > > >> existing programs.
>> >> > > >>
>> >> > > >> But this is still a bit surprising behavior is it not?
>> >> > > >>
>> >> > > >> Thanks,
>> >> > > >> Amir.
>> >> > > >
>> >> > > > I'm not sure what to do with it.
>> >> > > >
>> >> > > > If we allow to change btime of ntfs then for consistency we should also
>> >> > > > allow to change btime of ext4.
>> >> > > >
>> >> > > > Maybe another idea... define new capability which would allow to change
>> >> > > > btime (on any filesystem)? This would at least make the consistency.
>> >> >
>> >> > Pali, I think this is a very bad idea.
>> >>
>> >> Ok, if the point is that ext4 btime must stay immutable then it is a bad idea.
>> >>
>> >> > This has nothing to do with capabilities.
>> >> > The Windows and MacOS filesystems have allowed setting their
>> >> > "creation time" forever
>> >>
>> >> FreeBSD for some fs allow it too (see below).
>> >>
>> >> > and for all the other Linux filesystems that had
>> >> > "birth time" it was immutable, so let's not mix filesystem features
>> >> > with capabilities.
>> >>
>> >> I think that it is important to first define behavior and invariants of
>> >> these "btime" and "ptime" kernel properties.
>> >>
>> >> If we want to be consistent then there are two possible options:
>> >>
>> >> 1. If we choose that the STATX_BTIME is immutable then no kernel fs
>> >>    driver should allow to change.
>> >>
>> >> 2. If we choose that the "NTFS create time" is reported via STATX_BTIME
>> >>    then STATX_BTIME is not immutable at all.
>> >>
>> >> These two options cannot be chosen together because option 1 would
>> >> implie that the modifiable "NTFS create time" cannot be reported over
>> >> STATX_BTIME.
>> >>
>> >> We are have currently STATX_BTIME immutable and "NTFS create time"
>> >> reported via STATX_BTIME.
>> >>
>> >> If we want to stay _consistent_ across fs drivers then adding API for
>> >> changing "NTFS create time" would break one of those two things.
>> >>
>> >> In my opinion we should stay consistent across filesystem drivers and
>> >> provide unified behavior of APIs independently of used filesystem.
>> >> Otherwise userspace applications would have to write fs specific code
>> >> for doing their use cases (and we can stay with fs-specific xattrs, no
>> >> need to create unified APIs).
>> >>
>> >> Does it make sense? Or it is still a bad idea to think about it in this way?
>> >>
>> >
>> > My "bad idea" comment was only referring to capability.
>> >
>> > w.r.t the STATX_BTIME ambiguity there is another option we may want to
>> > consider: Don't publish STATX_PTIME via statx() at all.
>> >
>> > One of the reasons that developers have pointed to fileattr as the right API
>> > to host the creation time as well as the DOS attributes is that it has a history
>> > of carrying filesystem specific attributes.
>> >
>> > Not every attribute available in lsattr is also available in statx().
>> > If projid is not available in statx() then the settable creation time
>> > doesn't need to be in statx() either.
>> >
>> > The file_[sg]etattr() syscalls provides a symmetric API to set/get it.
>> 
>> btime currently is also a fliesystem specific implementation tho, and
>> there was already a transition from stat to statx when btime was added,
>> so I think ptime should be included in statx, especially since it should
>> be treated as one of the standard timestamps from now on (or at least,
>> that's what I hope to achieve eventually).
>> The only difference to the currently standard timestamps would be that
>> a/mtime are managed by utimensat, ctime/btime by the filesystems
>> themselves (as they're more "internal" and less "user-facing") and ptime
>> would be managed by file_[gs]etattr() (since changing utimensat wouldn't
>> make sense as said in the april thread).
>
> Not related to these changes, but I think it would make sense to adjust
> also utimensat man page documentation and mention there what kind of
> syscall/function will be used for changing ptime. From my experience,
> such cross reference can help developers. Also the fact is that FreeBSD
> changes birth time via utimes syscall could mean that developers could
> look for similar Linux functionality in linux utime* manpages.

Right, I'll add some quick draft/mention in the manpage for next series,
just to remember to include this in the final patch (and to get feedback
on this point too).

Thanks,
koraynilay

>> 
>> > The same could be true to HIDDEN/ARCHIVE/SYSTEM flags if those
>> > are added to fileattr.
>> >
>> > Do we need to stop publishing NTFS creation time in STATX_BTIME?
>> > I think it's too late for that and nobody is going to gain anything
>> > from doing that.
>> >
>> > Thanks,
>> > Amir.
>> 
>> 



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]