Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Unix.lockf doesn't behave correctly on Windows #7264

Closed
vicuna opened this issue May 23, 2016 · 3 comments
Closed

Unix.lockf doesn't behave correctly on Windows #7264

vicuna opened this issue May 23, 2016 · 3 comments
Labels
bug platform-support
Milestone
4.05.0

Comments

@vicuna
Copy link

vicuna commented May 23, 2016 •
edited by dra27

Original bug ID: 7264
Reporter: @dra27
Status: resolved (set by @xavierleroy on 2017-02-16T08:39:02Z)
Resolution: fixed
Priority: normal
Severity: major
Version: 4.02.2
Target version: 4.05.0 +dev/beta1/beta2/beta3/rc1
Fixed in version: 4.05.0 +dev/beta1/beta2/beta3/rc1
Category: platform support (windows, cross-compilation, etc)
Monitored by: @dbuenzli

Bug description

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 = <abstr>
# Unix.(lockf fd F_LOCK 0);;
- : unit = ()
# Unix.(write_substring fd "foo" 0 3);;
- : int = 3
# let fd2 = Unix.(openfile "foo" [O_CREAT; O_RDWR] 0o666);;
val fd2 : Unix.file_descr = <abstr>
# Unix.(write_substring fd2 "foo" 0 3);;
Exception: Unix.Unix_error (Unix.EACCES, "write", "").
@vicuna
Copy link
Author

vicuna commented May 25, 2016

Comment author: @dra27

I've done a bit more investigation here and found two more things:

  1. Lock promotion doesn't work - i.e. Unix.(lockf fd F_RLOCK 0; lockf fd F_LOCK 0) will block
  2. Blocking out other file handles within the same thread/process is the intended behaviour of the LockFile Windows API call

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.

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

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.

@vicuna
Copy link
Author

vicuna commented Feb 16, 2017

Comment author: @xavierleroy

Updated the documentation of Unix.lockf to mention this difference between Win32 and POSIX.

@vicuna vicuna closed this as completed Feb 16, 2017
@vicuna vicuna added this to the 4.05.0 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug platform-support
Projects
None yet
Milestone
4.05.0
Development

No branches or pull requests
1 participant
@vicuna