flock(1): working with fcntl locks

[Kjetil Torgrim Homme <kjetil.homme@redpill-linpro.com>]

I was a bit surprised to find that flock(2) specifically ignores fcntl 
locks.  from its manual page:

        Since  kernel  2.0,  flock() is implemented as a system call in 
its own
        right rather than being emulated in the GNU C  library  as a  
call  to
        fcntl(2).   This  yields  true  BSD  semantics: there is no 
interaction
        between the types of lock placed by flock() and fcntl(2), and  
flock()
        does not detect deadlock.

I was trying to check if dpkg or apt-get was holding its lock and skip 
running my cron job if so, but unfortunately it uses fcntl (F_SETLK), 
and flock(1) will happily call flock(2) which succeeds.

it's a bit sad to have to write the lock testing in C or Perl rather 
than use the nice little flock(1), so I wonder if we could "fix" 
flock(1) somehow.  I think I'm not alone to be surprised that flock(1) 
is so ineffective against locking done by other utilities, so my 
prefered solution would be to switch to using fcntl(2).

the chance of a problematic regression is small, I think.  my *guess* is 
that most flock(1) usage is only interacting with other usage of 
flock(1) (not flock(2)).  also relying on flock(1) succeeding on a 
fcntl-locked file would be just Wrong(tm).

the "safe" solution is to add a flag, --fcntl, but isn't that just cruft?

I can provide patches when I hear what the mailing list wants.

-- 
Kjetil T. Homme
Redpill Linpro - Changing the game