Rev 4715: (mbp) better message if lockdir disappears after apparently succeeding in file:///home/pqm/archives/thelove/bzr/2.0/

[Canonical.com Patch Queue Manager]

At file:///home/pqm/archives/thelove/bzr/2.0/

------------------------------------------------------------
revno: 4715 [merge]
revision-id: pqm at pqm.ubuntu.com-20091222061855-scbiyuohoxoltr1y
parent: pqm at pqm.ubuntu.com-20091221185059-vuinz3m0zbxvsh49
parent: mbp at sourcefrog.net-20091222041041-mkblefcp1onetkzb
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: 2.0
timestamp: Tue 2009-12-22 06:18:55 +0000
message:
  (mbp) better message if lockdir disappears after apparently succeeding
modified:
  NEWS                           NEWS-20050323055033-4e00b5db738777ff
  bzrlib/lockdir.py              lockdir.py-20060220222025-98258adf27fbdda3
=== modified file 'NEWS'
--- a/NEWS	2009-12-21 16:45:39 +0000
+++ b/NEWS	2009-12-22 04:10:41 +0000
@@ -31,6 +31,9 @@
   This will likely have an impact on any other process that is serving for
   an extended period of time.  (John Arbash Meinel, #494406)
 
+* Give a clearer message if the lockdir disappears after being apparently
+  successfully taken.  (Martin Pool, #498378)
+
 * The 2a format wasn't properly restarting autopacks when something
   changed underneath it (like another autopack). Now concurrent
   autopackers will properly succeed. (John Arbash Meinel, #495000)

=== modified file 'bzrlib/lockdir.py'
--- a/bzrlib/lockdir.py	2009-07-27 05:24:02 +0000
+++ b/bzrlib/lockdir.py	2009-12-21 06:17:05 +0000
@@ -240,8 +240,16 @@
         # incorrect.  It's possible some other servers or filesystems will
         # have a similar bug allowing someone to think they got the lock
         # when it's already held.
+        #
+        # See <https://bugs.edge.launchpad.net/bzr/+bug/498378> for one case.
+        #
+        # Strictly the check is unnecessary and a waste of time for most
+        # people, but probably worth trapping if something is wrong.
         info = self.peek()
         self._trace("after locking, info=%r", info)
+        if info is None:
+            raise LockFailed(self, "lock was renamed into place, but "
+                "now is missing!")
         if info['nonce'] != self.nonce:
             self._trace("rename succeeded, "
                 "but lock is still held by someone else")