-
Notifications
You must be signed in to change notification settings - Fork 92
getLock unexpectedly can clear an existing lock belonging to a process #44
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
Comments
I'm not 100% sure if my C program is correct, but here is is for completeness. It seems to show that F_GETLK shouldn't clear a lock set by F_SETLK on a different Fd.
|
Thanks for the heads up, and particularly for the thorough test cases. I probably won't have time to play with this before tomorrow, but I'll be on it ASAP. For completeness, have you tried this test on 7.8 or under any other OS? If no to the latter, could you share which OS you're on (in the off case that it isn't reproducible on my machine)? |
I've been testing this on Linux. ghc 7.6.3/unix-2.6.0.1 also behave as Also just did a quick test on OSX, and I see the same behavior there see shy jo |
Having taken a look at this, I'm going to bounce it back to you for review. It seems to be performing to spec from my perspective. My rationale is below. Let me know if I've missed the problem you're seeing. I see appropriate locking behavior when the closeFd is removed from the "getLock" case. This is what I would expect per the following clause from the description of POSIX fcntl in the Linux fcntl documentation..
Linux provides open file description locks since 3.15 which don't have this behaviour, but they are Linux-specific and we don't (currently) support them. |
Elliot Robinson wrote:
Wow, ok. That's in spec, but certianly surprising behavior if not well I don't think that flock locks behave that way, do they? A user reading see shy jo |
Yep, POSIX is rife with such things. I've learned to read the spec first and then shut up and sit down. Mine is not to wonder why.
No, they don't. Unfortunately,
The assumption for me is that anything in System.Posix implements the standard, though I'll agree that the standard isn't always intuitive. I'll work on making this a bit more clear. |
So it seems this is invalid? Please re-open with further information if you disagree. |
I have a program that opens two different Fds to the same file, uses setLock on the first Fd, and then getLock on the second Fd. Once the getLock is done, the program no longer has a lock set on the file. This is with unix 2.7.0.1 and ghc 7.10.1.
This is very surprising (and is a testcase from stumbling over this problem in the wild), and I don't see behavior like this when I write a C program that does the same thing using fcntl F_SETLK and F_GETLK.
I'll paste my test program at the end of this bug report. The way to use it is open 2 terminals. In the first, run "./test setLock getLock". Then in the second, run "./test setLock" and see that it successfully sets the lock; the first process lost its lock on the file. If you instead run "./test setLock" in both terminals, it behaves as expected with the first process taking the lock so the second fails to take it.
The text was updated successfully, but these errors were encountered: