Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
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.