[BUG] "No locks available" on NFS (RHEL3WS update 5)

[Harald Meland]

I just tried using bzr on my NFS-mounted home directory, from a client
running "Red Hat Enterprise Linux WS release 3 (Taroon Update 5)".
Both 0.0.7 and the current bzr.dev fails like this:

  $ mkdir test
  $ cd test
  $ bzr init
  $ bzr diff
  bzr: ERROR: [Errno 37] No locks available
    at /work/bazaar-ng/bzr-0.0.7/bzrlib/lock.py line 105, in __init__()
    see ~/.bzr.log for debug information
  /work/bazaar-ng/bzr-0.0.7/bzrlib/lock.py:64: UserWarning: lock on <open file '/home/hmeland/.bzr.conf/plugins/bzrtools/.bzr/branch-lock', mode 'rb' at 0x402700f8> not released
    warn("lock on %r not released" % self.f)
  Exception exceptions.IOError: (37, 'No locks available') in <bound method _fcntl_ReadLock.__del__ of <bzrlib.lock._fcntl_ReadLock object at 0x4028eacc>> ignored

It appears that bzr is using fcntl.flock() to do locking, which on my
system actually invokes the flock(2) system call:

  $ strace -e trace=fcntl,flock bzr diff
  flock(4, LOCK_SH)                       = -1 ENOLCK (No locks available)
  bzr: ERROR: [Errno 37] No locks available
  [...]

The man page for flock(2) on my system says:

  NOTES
       flock(2) does not lock files over NFS.  Use fcntl(2) instead: that does
       work  over  NFS,  given  a  sufficiently  recent version of Linux and a
       server which supports locking.

As fcntl.lockf() is a wrapper around fcntl(2) with a superset of
fcntl.flock()'s call syntax, and fcntl(2) locking *does* work over
NFS, maybe bzr should use that instead?

(Let me know if you'd like to see the full traceback; I suspect it
isn't very relevant in this case.)
-- 
Harald