[OpenAFS] Re: File locking

Stephan Wiesand stephan.wiesand@desy.de
Thu, 17 Jul 2014 21:35:43 +0200


unless there's a problem found with it, this patch will be part of the =
next ordinary stable release.

Thanks a lot for reporting your problems with 1.6 and reporting back on =
the proposed fix. And Kudos to Andrew for whipping that up so swiftly.


On Jul 17, 2014, at 21:20 , Todd Lewis wrote:

> Andrew,
> The suggested patch was applied, installed, and our application now =
works correctly again with the new client.
> Thank you very much for your timely response. Looking forward to this =
patch making its way to release soon.
> --
> Todd_Lewis@unc.edu
> On 07/17/2014 11:59 AM, Andrew Deason sent:
>> On Thu, 17 Jul 2014 10:07:07 -0400
>> Todd Lewis <Todd_Lewis@unc.edu> wrote:
>>> Was there some change in file locking semantics that would make =
>>> of this? Does this application tickle a corner case error in =
>>> file locking, or does more rigorous lock handling in the newer =
>>> expose a bug in the application? I have tried to replicate the =
>>> with a very simple C program with no success, but that mostly
>>> indicates I'm not sure what I'm testing for.
>> I assume the path you gave was for an RO volume, yes?
>> In that case, no, it's just a mistake; specifically, my mistake =
>> It's trying to return the error EBADF (9) to you, which is wrong, and
>> it's returning that code incorrectly, which makes this a bit more
>> confusing.
>> There was some code added a while back to skip some processing for =
>> on RO volumes. But for some reason I added some linux-specific check
>> much earlier before the platform-agnostic check, which makes this =
>> for F_GETLK requests in addition to F_SETLK ones. (For F_SETLK, we
>> should indeed fail with EBADF here.) I'm not sure why I did that, =
>> this should have been handled by the platform-agnostic code; none of =
>> notes or comments about this seem to say anything about it.
>> And in that Linux-specific check, the error is just plain returned
>> incorrectly (which just happens from time to time, since Linux has a
>> very specific different way of doing this). I think I just didn't =
>> this when running it originally (and almost missed it just now), =
>> I saw a '9' get returned and assumed that's what was supposed to =
>> But it's not, of course; fcntl is supposed to return -1 and set errno =
>> 9.
>> A proposed fix is here (gerrit 11316):
>> =
>> If you are able to test code changes in your client, give that a try.

Stephan Wiesand
Platanenenallee 6
15738 Zeuthen, Germany