On Wed, 01/18 14:02, Max Reitz wrote: > >> Testing whether something is locked would be easier by using F_OFD_GETLK > >> instead of actually creating an exclusive lock and then releasing it. > > > > My attempt to do this shows it doesn't work: fcntl forces the tested lock > > type > > to read lock for some unknown reason, so it cannot be used to test other > > shared > > lockers. > > Do you have a reproducer? The attached quick and dirty test case works > for me (compile test.c to test and test2.c to test2), producing the > following output (when running ./test): > > set rd lock: 0, Success > get lock: 0, Success; read lock in place > set wr lock: -1, Resource temporarily unavailable > unset lock: 0, Resource temporarily unavailable > === > unset lock: 0, Success > get lock: 0, Success; unlocked > set wr lock: 0, Success > unset lock: 0, Success > === > set wr lock: 0, Success > get lock: 0, Success; write lock in place > set wr lock: -1, Resource temporarily unavailable > unset lock: 0, Resource temporarily unavailable
You are right, now I see why I was confused with the F_OFD_GETLK interface. Fam > > So the l_type field is correctly set after every F_OFD_GETLK query call. > > Max
