Windows: opening file in append mode breaks locking (?)

[pkgw]

I think that std::fs has a bug in the interaction between the OpenOptions and file locking on Windows.

Consider the following test program, using the fs2 crate:

extern crate fs2;

use fs2::FileExt;
use std::fs;

fn main() {
    let f = fs::OpenOptions::new()
            .create(true)
            .append(true)
            .open("myfile.txt").expect("error creating");
    f.lock_exclusive().expect("error locking");
}

On Windows 10 this fails for me:

    Finished dev [unoptimized + debuginfo] target(s) in 0.99s                                                           
     Running `target\debug\examples\debug.exe`                                                                          
thread 'main' panicked at 'error locking: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }', libcore
\result.rs:945:5                                                                                                        
note: Run with `RUST_BACKTRACE=1` for a backtrace.                                                                      
error: process didn't exit successfully: `target\debug\examples\debug.exe` (exit code: 101)   

If I use .write(true) instead of .append(true), it works fine.

I believe that what's happening here is that the append mode is setting too many flags. Here's the relevant code in the Windows FS implementation. Based on this MS doc page, my guess is that the Rust code is somehow interacting with the Windows SYNCHRONIZE flag in a way that's causing problems.

However, I'm not a native Windows dev so this isn't my area of expertise, and it's a bit tricky for me to investigate this in detail. But I can't find any evidence on the internet that the error above is an expected behavior.

[retep998]

Might it be that LockFileEx requires FILE_WRITE_DATA?

[pkgw]

OK, the docs say that the handle must be opened with GENERIC_READ or GENERIC_WRITE. I guess it doesn't work since .appendt(true) alone doesn't provide all of the needed flags.

But if I add .read(true), I can lock the file. That's a bit funky, but I guess I'm more inclined to say that that's something that should be documented in fs2 rather than anything that requires code changes in std. What do you think?

[pkgw]

OK, the docs say that the handle must be opened with GENERIC_READ or GENERIC_WRITE. I guess it doesn't work since .appendt(true) alone doesn't provide all of the needed flags.

But if I add .read(true), I can lock the file. That's a bit funky, but I guess I'm more inclined to say that that's something that should be documented in fs2 rather than anything that requires code changes in std. What do you think?

[pitdicker]

.append(true) doesn't set all the bits of GENERIC_WRITE, it misses the FILE_WRITE_DATA bit as @retep998 mentioned. But I can't guess why LockFileEx requires them all. Maybe it's checks are just not fine-grained enough.
Seems like there is not much that can be done except documenting.

[pkgw]

Again, I'm not a Windows expert, but I'm inclined to say the same. Feel free to close if you think there's nothing to do on the rust-lang side.

[tom2o17]

Any status/update on this was playing with a tool on both windows and unix.

append(True) -> write(True) fixed the issue for me

but if this is just the result of poor windows config will not make a PR for the tool

[ChrisDenton]

The documentation for LockFile says that the file must be opened with GENERIC_READ or GENERIC_WRITE access, which equates to either read(true) or write(true) in Rust.

So yes, when appending the file will need to be opened with either .read(true).append(true) or .write(true) otherwise LockFile won't work. The only alternative would be for Rust to change append(true) to be an alias of write(true) on Windows. I don't think this is desirable and would break people who expect append to actually mean append. Therefore I'm closing this issue,