[BUG] 9p filesystem does not honor turning off O_APPEND if a file handle is opened with O_APPEND

[BUG] 9p filesystem does not honor turning off O_APPEND if a file handle is opened with O_APPEND

[Khánh Trần Ngọc]

Hello,

I recently found a bug while interacting with 9p filesystems on WSL. If a handle is opened with O_APPEND, then this flag can no longer be removed using F_SETFL despite 9pfs misreporting that the flag was removed successfully. The underlying filesystem continues to append to the end while the O_APPEND flag is gone when F_GETFL is called, and the seek cursor continues to progress as if removing O_APPEND actually worked.

If removing O_APPEND is not meant to be supported, F_SETFL should have returned an error (EPERM seems to be the most suitable as that handle may only append data). 

Tested environment:
WSL version: 2.6.3.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.71
MSRDC version: 1.2.6353
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8457

Original issue: https://github.com/microsoft/WSL/issues/40649

Thanks,

Khanh

Re: [BUG] 9p filesystem does not honor turning off O_APPEND if a file handle is opened with O_APPEND

[Dominique Martinet]

+linux-fsdevel@ in to

Khánh Trần Ngọc wrote on Thu, May 28, 2026 at 06:55:45AM +0000:
> I recently found a bug while interacting with 9p filesystems on
> WSL. If a handle is opened with O_APPEND, then this flag can no longer
> be removed using F_SETFL despite 9pfs misreporting that the flag was
> removed successfully. The underlying filesystem continues to append to
> the end while the O_APPEND flag is gone when F_GETFL is called, and
> the seek cursor continues to progress as if removing O_APPEND actually
> worked.
> 
> If removing O_APPEND is not meant to be supported, F_SETFL should have
> returned an error (EPERM seems to be the most suitable as that handle
> may only append data).

Thanks for the report, it's definitely a bug, but I'm not quite sure how
to deal with it...
As I see it (setfl() in fs/fcntl.c), we have two choices: flag every
inodes as S_APPEND so the IS_APPEND() check fails, but I'm afraid that
will have other side effects somewhere; or we need to update the
check_flags() file operation to pass the filp (or at least
filp->f_flags) so we can decide if the O_APPEND flag changed...

Thanksfully only nfs seems to be using check_flags(), so I think that
way is likely to be the easiest, but it's likely to take a bit of time.

If someone closer to the vfs has an opinon that'd be welcome.


(leaving the rest of the original mail below for anyone not on v9fs@)
> 
> Tested environment:
> WSL version: 2.6.3.0
> Kernel version: 6.6.87.2-1
> WSLg version: 1.0.71
> MSRDC version: 1.2.6353
> Direct3D version: 1.611.1-81528511
> DXCore version: 10.0.26100.1-240331-1435.ge-release
> Windows version: 10.0.26200.8457
> 
> Original issue: https://github.com/microsoft/WSL/issues/40649

Thanks,
-- 
Dominique Martinet | Asmadeus