Unix.lockf doesn't behave correctly on Windows #7264
Original bug ID: 7264
Unix.lockf on Windows seems to lock out file handles on the same file for the current process as well.
Steps to reproduce
In a toploop with unix.cma loaded:
let fd = Unix.(openfile "foo" [O_CREAT; O_RDWR] 0o666);;
val fd : Unix.file_descr =
Unix.(lockf fd F_LOCK 0);;
Unix.(write_substring fd "foo" 0 3);;
let fd2 = Unix.(openfile "foo" [O_CREAT; O_RDWR] 0o666);;
val fd2 : Unix.file_descr =
Unix.(write_substring fd2 "foo" 0 3);;
Exception: Unix.Unix_error (Unix.EACCES, "write", "").
Comment author: @dra27
I've done a bit more investigation here and found two more things:
I can see how the Unix module could work around problem 1 (it's just yet another instance of needing to add information to the fd structure!), but I can't see an easy way to work around the other problem without having to track all open file descriptors and re-map them.
Comment author: @xavierleroy
Clearly, POSIX and Win32 give different semantics to file locks. I think it is hopeless to commit on one semantics and emulate it on the other OS (or one both): this sounds technically very difficult, and moreover it's not obvious to me which semantics is the right one! My proposal is just to document the differences in behavior.