From: Baolin Liu <liubaolin@kylinos.cn>

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.

Tested in QEMU on an NTFS volume, both with chattr(1)/lsattr(1) and with
a test binary issuing the ioctls directly:
 - chattr +i/+a/+d each set the flag and lsattr reads it back
 - appending to a +i file fails with EPERM
 - statx(2) reports STATX_ATTR_NODUMP once nodump is set, and stops
   reporting it once cleared
 - FS_COMPR_FL is rejected with EOPNOTSUPP
 - lsattr reports 'c' on a compressed file
 - chattr -i/-a/-d clear the flags, and a flag set before unmounting is
   gone after dropping caches and mounting again

Baolin Liu (2):
  ntfs: implement fileattr_get and fileattr_set
  ntfs: support the nodump flag

 fs/ntfs/file.c  | 65 ++++++++++++++++++++++++++++++++++++++++++++++++-
 fs/ntfs/inode.c |  1 +
 fs/ntfs/inode.h |  1 +
 fs/ntfs/ntfs.h  |  4 +++
 4 files changed, 70 insertions(+), 1 deletion(-)

-- 
2.51.0

On Tue, Sep 1, 2026 at 6:15 PM Baolin Liu <liubaolin12138@163.com> wrote:
>
> From: Baolin Liu <liubaolin@kylinos.cn>
>
> 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?

在 2026/9/2 09:44, Namjae Jeon 写道:
> On Tue, Sep 1, 2026 at 6:15 PM Baolin Liu <liubaolin12138@163.com> wrote:
>>
>> From: Baolin Liu <liubaolin@kylinos.cn>
>>
>> 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.

On Tue, Sep 8, 2026 at 5:31 PM liubaolin <liubaolin12138@163.com> wrote:
>
>
>
> 在 2026/9/2 09:44, Namjae Jeon 写道:
> > On Tue, Sep 1, 2026 at 6:15 PM Baolin Liu <liubaolin12138@163.com> wrote:
> >>
> >> From: Baolin Liu <liubaolin@kylinos.cn>
> >>
> >> 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.

在 2026/9/2 09:44, Namjae Jeon 写道:
> On Tue, Sep 1, 2026 at 6:15 PM Baolin Liu <liubaolin12138@163.com> wrote:
>>
>> From: Baolin Liu <liubaolin@kylinos.cn>
>>
>> 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,

   You are right about inode reclaim, I had not considered that - not just
   a remount, memory pressure or drop_caches can silently drop these flags
   as well.

   I will look into how to persist them without breaking compatibility.


   Thanks for the review.

Thanks,
Baolin