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 noticed that you are opening the file read only, does the file you are
locking reside on a read only volume? I know there were some changes in
commit 0fc27471e7da0c5de4addcdec1bfbca5208072cc related to this.
commit 0fc27471e7da0c5de4addcdec1bfbca5208072cc
Author: Andrew Deason <adea...@sinenomine.net>
Date: Tue Oct 2 14:38:20 2012 -0500
afs: Avoid tracking file locks for RO volumes
Advisory file locks for RO volumes don't make a lot of sense, since
there are no possible writes to worry about. The fileserver already
does not track these, so don't even bother processing them in the
client.
Change-Id: Ie2a20d2f7af67799cfb8d30e72aa3e52a1ecc2d5
Reviewed-on: http://gerrit.openafs.org/8197
Tested-by: BuildBot <build...@rampaginggeek.com>
Reviewed-by: Derrick Brashear <sha...@your-file-system.com>
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
