Re: [PATCH 0/2] ntfs: wire up the fileattr API

[Namjae Jeon]

On Tue, Sep 8, 2026 at 5:31 PM liubaolin <liubaolin12138@xxxxxxx> wrote:
>
>
>
> 在 2026/9/2 09:44, Namjae Jeon 写道:
> > On Tue, Sep 1, 2026 at 6:15 PM Baolin Liu <liubaolin12138@xxxxxxx> wrote:
> >>
> >> From: Baolin Liu <liubaolin@xxxxxxxxxx>
> >>
> >> This series implements fileattr_get and fileattr_set for ntfs so that
> >> lsattr(1) and chattr(1) work on ntfs.
> >>
> >> Patch 1 wires up the fileattr inode operations and implements support
> >> for FS_IMMUTABLE_FL and FS_APPEND_FL. These flags map to inode->i_flags
> >> (S_IMMUTABLE, S_APPEND), so the VFS enforces them. fileattr_get also
> >> reports the compressed and encrypted state, which the driver already
> >> exposes through STATX_ATTR_* in ntfs_getattr().
> >>
> >> Patch 2 adds FS_NODUMP_FL support, which dump(8) and other backup tools
> >> use to mark files to skip. The flag is stored in a new ntfs_inode field
> >> and reported through both fileattr_get (for lsattr) and ntfs_getattr()
> >> (as STATX_ATTR_NODUMP, for statx), so the two interfaces stay consistent.
> >>
> >> All three accepted flags (immutable, append-only, nodump) are kept in
> >> memory and do not survive a remount, matching ntfs3 behavior.
> > This patch-set does not persist these flags on disk. So, the settings
> > survive only while the corresponding inode remains cached. inode
> > reclaim caused by memory pressure or drop_caches can discard them
> > before unmount. Could you find a way to persist immutable, append, and
> > nodump in metadata without causing compatibility issues?
>
> Hi Namjae,Hyunchul,
>
>    Regarding the persistence concern, I propose storing the
> Linux-specific flags in one private EA entry in the file's existing NTFS
> $EA attribute:
>
>      EA name:  $LXFLAGS
>      EA value: a 32-bit little-endian bitmask
>
>      bit 0: immutable
>      bit 1: append-only
>      bit 2: nodump
>
>    The three flags are boolean states, so one bit is sufficient for each
> of them. Using one 32-bit value also leaves room for future expansion.
>
>    This would add an EA entry named $LXFLAGS to the existing $EA
> attribute;it would not introduce a new NTFS attribute type. The driver
> already uses the standard $EA/$EA_INFORMATION mechanism for $LXUID,
> $LXGID, $LXMOD and $LXDEV, so this approach would reuse the existing
> on-disk mechanism.
>
>    The inode loading path would restore the flags from $LXFLAGS, and
> fileattr_set() would update the entry. The entry would be removed when
> all three flags are cleared. This would allow the flags to survive inode
> reclaim, drop_caches, unmount/remount, and reboot.
>
>    This approach would not require changes to mkntfs or to the NTFS
> filesystem format.
>
>    Would this approach be acceptable? If so, I will implement it and
> submit a new revision as soon as possible.
Could you please check whether Windows CHKDSK or the Windows NTFS
modifies or deletes this EA? If neither modifies nor deletes it,
please implement the proposed approach.

Thanks.