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@xxxxxxxxxx> wrote:
> >> >
> >> > On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote:
> >> > > On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger <adilger@xxxxxxxxx> wrote:
> >> > > >
> >> > > > On Nov 2, 2026, at 09:38, Pali Rohár <pali@xxxxxxxxxx> 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@xxxxxxxxxx> 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.