LockableFiles warning conceals real exception

[RayH]

I'm having problems with a lock file in Bazaar on Windows using a remote repository.

I have been using this sucessfully from the Linux and Windows side to develop portable PERL code, but now something on the lock side seems to have gone wrong. bzr update shows trees on both machines are up to date. But Windows can longer commit.....

bzr commit -m "Scanned all files to replace SQL concat with placeholders."
Connected (version 2.0, client OpenSSH_4.6p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
Opened sftp connection (server version 3)
Committing to: sftp://<email address hidden>:1022///home/bzr/webAAA/trunk/
modified bin/installWebAAA.pl
modified libs/webAAA.pm
modified libs/webAAAAdmin.pm
modified libs/webAAAExtra.pm
modified libs/webAAALogin.pm
modified libs/webAAARegister.pm
bzr: ERROR: Permission denied: "4c/installwebaaa.pl-20080429104456-b586jfz3dn1m3
hin-1.knit": [Errno 13] Permission denied
C:\Program Files\Bazaar\lib\library.zip\bzrlib\lockable_files.py:110: UserWarnin
g: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C
:/NMS/Globis/ExtraNet/.bzr/repository/>) was not explicitly unlocked

How do I clear this situation? It seems to be a local Windows lock file.

[RayH (ray-hunter)]

BTW I tried

bzr break-lock
bzr break-lock full_local_path
bzr break-lock full_sftp_path

no joy.

[RayH (ray-hunter)]

OK I cleared it manually. Here's how.

I deleted the source code file completely that was causing the problem (saving a copy in an editor).

I then committed all the other outstanding changes to the repository.

I then recreated the file.

then bzr add .\bin\installWebAAA.pl

then I committed again with this change.

All OK. Odd, but that's windows.

[Matthieu Moy (matthieu-moy)]

RayH <email address hidden> writes:

> bzr commit -m "Scanned all files to replace SQL concat with placeholders."

> ** Affects: baz

bzr != baz ;-).

Can you report the bug to the correct project?

Thanks,

--
Matthieu

[James Westby (james-w)]

Hi,

I am reassigning this to the correct project.

Thanks,

James

[RayH (ray-hunter)]

You can close this bug.

It hasn't recurred since upgrading my client and the server versions.

Thanks.

[RayH (ray-hunter)]

Does not occur with newer versions of bzr (>=1.3).

[Vincent Ladeuil (vila)]

Fixing status in case someone else encounter the bug with on older version.

[John A Meinel (jameinel)]

So, I think RayH was a bit off in his analysis, there are 2 bits:

bzr: ERROR: Permission denied: "4c/installwebaaa.pl-20080429104456-b586jfz3dn1m3hin-1.knit": [Errno 13] Permission denied

The action was failing because of a permission issue. Fixing the permission issue would have resolved this for any version of bzr.

C:\Program Files\Bazaar\lib\library.zip\bzrlib\lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C:/NMS/Globis/ExtraNet/.bzr/repository/>) was not explicitly unlocked

^- This is a separate issue, that we gave a warning that a lock wasn't properly cleaned up.
In 1.8 (I believe) Martin will merge his change to suppress these warnings, as they are generally more confusing than helpful. I also see this in bzr 1.4:

* If a ``LockableFiles`` object is not explicitly unlocked (for example
  because of a missing ``try/finally`` block, it will give a warning but
  not automatically unlock itself. (Previously they did.) This
  sometimes caused knock-on errors if for example the network connection
  had already failed, and should not be relied upon by code.
  (Martin Pool, #109520)

But that is something a little bit different.

[RayH (ray-hunter)]

> The action was failing because of a permission issue. Fixing the permission issue would have resolved this for any version of bzr.

Ah ok. Then the real root cause of the permission issue probably lies even deeper. Our remote repository was stored on a Linux machine as user 'bzr' and using a standard ext3 filesystem. I was accessing the repository using sftp on a windows machine and logging in as user 'rayH' from the same user group. The SFTP transport may not have headed the sticky bit on the directory (sgid) when creating the new files. That is a known issue. see Bug 50568: I now use ssh transport wherever possible.