bzr status gives ugly traceback in read-only tree

[James Troup]

I accidently ran bzr status in a bzr tree as the wrong user and was greeted with this:

$ bzr st
unknown:
  config/canonical-admin
bzr: ERROR: [Errno 13] Permission denied: '/srv/archive.admin.canonical.com/dak/.bzr/checkout/stat-cache.27985.adelie.tmp'
/usr/lib/python2.4/site-packages/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///srv/archive.admin.canonical.com/dak/.bzr/checkout/>) was not explicitly unlocked
  warn("file group %r was not explicitly unlocked" % self)
/usr/lib/python2.4/site-packages/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///srv/archive.admin.canonical.com/dak/.bzr/branch/>) was not explicitly unlocked
  warn("file group %r was not explicitly unlocked" % self)
/usr/lib/python2.4/site-packages/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///srv/archive.admin.canonical.com/dak/.bzr/repository/>) was not explicitly unlocked
  warn("file group %r was not explicitly unlocked" % self)
$

Now obviously it'd be nice if bzr status just worked in a read-only tree (and I believe there's a bug about this already), but at the very least that ugly-as-sin pseudo-traceback output needs to die.

[Jelmer Vernooij (jelmer)]

Bazaar shouldn't use the stat cache if it doesn't have write access or perhaps use another, temporary directory?

[John A Meinel (jameinel)]

This was a long-standing bug that was fixed a while ago, but I guess the fix never made it in.

Notice that 'bzr status' actually worked, it just failed when it wanted to write the new information.

Something like this:
=== modified file 'bzrlib/workingtree.py'
--- bzrlib/workingtree.py 2006-12-17 17:42:43 +0000
+++ bzrlib/workingtree.py 2006-12-18 18:10:47 +0000
@@ -1765,7 +1765,10 @@
             if self._inventory_is_modified:
                 self.flush()
             if self._hashcache.needs_write:
- self._hashcache.write()
+ try:
+ self._hashcache.write()
+ except IOError:
+ pass
         # reverse order of locking.
         try:
             return self._control_files.unlock()

Should fix it. I think the problem was being unsure where the right fix should go, and whether it should warn or not. And it just got dropped.

[Martin Pool (mbp)]

On 19/12/2006, at 5:12am, John A Meinel wrote:

> Something like this:
> === modified file 'bzrlib/workingtree.py'
> --- bzrlib/workingtree.py 2006-12-17 17:42:43 +0000
> +++ bzrlib/workingtree.py 2006-12-18 18:10:47 +0000
> @@ -1765,7 +1765,10 @@
> if self._inventory_is_modified:
> self.flush()
> if self._hashcache.needs_write:
> - self._hashcache.write()
> + try:
> + self._hashcache.write()
> + except IOError:
> + pass
> # reverse order of locking.
> try:
> return self._control_files.unlock()
>
> Should fix it. I think the problem was being unsure where the right
> fix
> should go, and whether it should warn or not. And it just got dropped.

+1 for that, even if we eventually move it elsewhere.

--
Martin

[John A Meinel (jameinel)]

There is a fix in the associated branch.