Windows file locking with bzr 2.2.3

[Eli Zaretskii]

> Date: Thu, 24 Feb 2011 15:47:52 -0600
> From: John Arbash Meinel <john at arbash-meinel.com>
> Cc: bazaar at lists.canonical.com, Michael Chaffin <chaffinmichael at gmail.com>,
> 	be-devel at bugseverywhere.org
> 
> Just to clarify a bit. fcntl locking on Unix (just Linux?) allows a
> single process to lock a file with both a shared lock and an exclusive
> lock. Any other process will be blocked once an exclusive lock is taken.
> 
> On Windows, taking an exclusive lock blocks all other requests, even
> from the same process. IMO Windows makes more sense here, for whatever
> the purpose of locking the file, most logic will assume they got what
> they asked for. (Thread1 thinks it has an exclusive lock, so does
> thread2, but they can both mutate the state on Linux.)

Are you saying that there are subtle bugs in bzr on GNU/Linux, due to
this feature of the locks?  If so, did you ever hear complaints that
could be traced to those bugs?

If there were no complaints, perhaps you could conclude that this
potential problem is purely theoretical, and similarly lax application
of locks on Windows would be possible?

You see, this exclusive lock thing is a constant source of annoyance
for me on Windows.  Whenever "bzr ci" runs in a versioned tree, almost
every other command will fail, even "bzr status".  Coupled with the
fact that "bzr ci" could take some time (in my case, 1-2 minutes are
not uncommon), and that Emacs runs "bzr status" on each file you visit
in a versioned tree, this is a real nuisance.  I need to sit tight
doing nothing until "bzr ci" finishes.

Can something be done about that, please?  Maybe bzr could hold the
lock for shorter periods of time?

This is bzr 2.3.0, btw.  But I saw the same problems with 2.2.3 and
older versions.

TIA