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 wrote: >> >> >> >> On Tuesday 03 November 2026 09:23:32 Amir Goldstein wrote: >> >> > On Tue, Nov 3, 2026 at 2:19 AM Andreas Dilger wrote: >> >> > > >> >> > > On Nov 2, 2026, at 09:38, Pali Rohár wrote: >> >> > > > >> >> > > > On Monday 02 November 2026 16:09:41 Amir Goldstein wrote: >> >> > > >> On Mon, Nov 2, 2026 at 3:24 PM Pali Rohár 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. >> >>