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

[liubaolin]

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

Thanks,
Baolin.