Todd,
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.
Stephan
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_le...@unc.edu
>
> On 07/17/2014 11:59 AM, Andrew Deason sent:
>> On Thu, 17 Jul 2014 10:07:07 -0400
>> Todd Lewis <todd_le...@unc.edu> wrote:
>>
>>> Was there some change in file locking semantics that would make sense
>>> of this? Does this application tickle a corner case error in openafs's
>>> file locking, or does more rigorous lock handling in the newer client
>>> expose a bug in the application? I have tried to replicate the failure
>>> 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 (sorry).
>> 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 locks
>> on RO volumes. But for some reason I added some linux-specific check
>> much earlier before the platform-agnostic check, which makes this fail
>> 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, since
>> this should have been handled by the platform-agnostic code; none of my
>> 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 notice
>> this when running it originally (and almost missed it just now), because
>> I saw a '9' get returned and assumed that's what was supposed to happen.
>> But it's not, of course; fcntl is supposed to return -1 and set errno to
>> 9.
>>
>> A proposed fix is here (gerrit 11316):
>> <http://git.openafs.org/?p=openafs.git;a=commitdiff_plain;h=93451d74474bcd8ed9e0f59cf690d3d61c3022f9>
>>
>> If you are able to test code changes in your client, give that a try.
--
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
