> From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Tuesday, 18 July 2017 8:07 > On 07/17/2017 07:33 PM, John Snow wrote: > > On 07/17/2017 07:30 PM, Andrew Baumann via Qemu-devel wrote: > >> I'm running a recent Linux build of qemu on Windows Subsystem for Linux > (WSL) which doesn't appear to implement file locking: > >> > >> $ qemu-system-aarch64 ... -drive file=test.vhdx,if=none,id=hd0 -device > virtio-blk-pci,drive=hd0 > >> qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to > unlock byte 100 > > Does WSL implement fcntl(F_SETLK) but not fcntl(F_OFD_SETLK)?
Yes, this appears to be the case (there's also one report that it's broken): https://github.com/Microsoft/BashOnWindows/issues/1927 > We > already have code in place for compiling when F_OFD_SETLK is not > supported (which makes lock=auto do nothing, and issues a warning that > F_SETLK locks may be ineffective when locks are explicitly requested), > do we need to just expand that code into a runtime test of whether > F_OFD_SETLK appears to be unsupported? That would be a nice fix, and it would avoid the need for yet another flag. On the other hand, WSL is aiming for ABI compatibility, so they should get around to implementing F_OFD_SETLK et al eventually. Even if this were fixed in QEMU or implemented in WSL, shouldn't there to be a way to turn snapshot file locking off on a per-drive basis? Andrew
