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

[khanhtranngoccva]

Windows Version

Microsoft Windows [Version 10.0.26200.8457]

WSL Version

2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 24.04.3 LTS on Windows 10 x86_64

Other Software

No response

Repro Steps

This is a test case written in high-level Rust. Most of the calls here can be mapped to simple raw syscalls. It uses crates.io dependencies nix, tokio and tempdir with any necessary features.

The file handle must be created in append mode, and then the append mode is switched off.

#[cfg(test)]
mod tests {
    use std::{io::SeekFrom, os::fd::AsFd};

    use nix::fcntl::{FcntlArg, OFlag};
    use tempdir::TempDir;
    use tokio::{
        fs::OpenOptions,
        io::{AsyncReadExt, AsyncSeekExt, AsyncWriteExt},
    };

    #[tokio::test]
    async fn test_appends_on_off() {
        // /mnt/d is a 9p location
        let tempdir = TempDir::new_in("/mnt/d/path/to/dir", "test_appends_on_off").unwrap();
        let mut file = OpenOptions::new()
            .create(true)
            .append(true)
            .read(true)
            .write(true)
            .open(tempdir.path().join("test.txt"))
            .await
            .unwrap();
        file.write_all(b"Hello, world!").await.unwrap();

        // Disable append mode
        let flags =
            OFlag::from_bits_retain(nix::fcntl::fcntl(file.as_fd(), FcntlArg::F_GETFL).unwrap());
        nix::fcntl::fcntl(
            file.as_fd(),
            FcntlArg::F_SETFL(flags & !nix::fcntl::OFlag::O_APPEND),
        )
        .unwrap();

        // In this error example, the underlying filesystem does not honor removing O_APPEND. So it appends to the end of the file.
        file.seek(SeekFrom::Start(7)).await.unwrap();
        file.write_all(b"earth!").await.unwrap();

        // The cursor should have been at position 19 due to the previous bug, but it is misreported as position 13. Therefore, the caller could not know that a bug occurred and proceeds as normal.
        let current_seek = file.seek(SeekFrom::Current(0)).await.unwrap();
        println!("current_seek: {}", current_seek);
        assert_eq!(current_seek, 13);

        file.seek(SeekFrom::Start(0)).await.unwrap();
        let mut buffer = Vec::new();
        file.read_to_end(&mut buffer).await.unwrap();
        println!("buffer: {:?}", String::from_utf8_lossy(&buffer));
        assert_eq!(buffer, b"Hello, earth!");
    }
}

Expected Behavior

The test case above should pass.

Actual Behavior

The test case above failed at the last line because the last write was treated as an append.

Diagnostic Logs

No response

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[khanhtranngoccva]

Logfile: WslLogs-2026-05-27_14-57-49.zip

[github-actions]

Diagnostic information

.wslconfig found
Detected appx version: 2.6.3.0

[chemwolf6922]

Hi @khanhtranngoccva , This is a limitation of the plan 9 protocol. As it has no means to change the open flags of a file after opening it. There might be workarounds in the p9 driver (in kernel). For example, move the append to the client side instead of the server side. But that may break multi client access.
There is not much we can do in the WSL repo. If you would like to request an upstream change or response, please consider report this via the p9fs mailing list.

[khanhtranngoccva]

I think if it's a limitation, then p9fs should at least return an error when calling SETFL to disable appends because currently trying to do so would "succeed" while causing an inconsistent state (the cursor is at the wrong position and the flag is incorrect). I am going to ask the mailing list now.