[Critical] dirstate format use OS file locking

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On 08/03/07, Alexander Belchenko <bialix at ukr.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I'm track down problem with LockError.
>>
>> Dirstate working tree format use old bzr locking mechanism (lock.py)
>> based on underlying OS locks.
>> This was used in the past. But it NEVER works correctly on win32 in
>> some cases
>> (especially 'bzr pull .' cause deadlock on win32 and cygwin).
>>
>> Now we have absolutely the same: on win32: after bzr obtain write lock
>> it *cannot* obtain read lock
>> on the same file. IIRC, in the end of 2005 year there was discussion
>> about this limitation, and
>> after this bzr switch to use lock-dirs.

Well, now we get a LockError rather than getting a deadlock, but it
still isn't what we want, I'm sure.


> 
> There were other reasons too, primarily that os locks can't be seen
> over network protocols.
> 
> Read locks are needed for dirstate because it can be updated in place,
> and isn't safe to read while that is happening.
> 
> If the locking problems are insoluble we could potentially go back to
> always replacing the whole thing.

Well, we do take a write lock on the whole directory using LockDir, it
is just that we also needed a read-lock on the file.

There are some comments in the code about not being able to os.rename()
over the file on win32 which is why it is "in-place". But we can't
change it anyway if there is a read-lock.

If a file is opened for reading on Windows its *path* is locked. Which
means that trying to rename it out of the way, and put a different file
in its place will fail.

> 
>> Now bzr reverts to old [buggy] behaviour.
>> For me this means that 0.15rc1 in current state is unusable on win32.
>> I don't know what to say more.
> 
> "We need to fix this before 0.15 final" :-)
> 
> We should fix it so that we do not try to take a read lock if we have
> a write lock.  I'm surprised we do; it's just a bug i think, not a
> design problem.
> 

Well, this goes back to some longstanding issues. I'm guessing they are
less serious for working trees than branches and repositories, though.
Specifically, if you do "bzr merge ../foo" you may need access to the
same Repository. One will get a read lock, and the other a write lock.

I don't know of any specific cases were we genuinely *need* a source
working tree in readonly and a destination workingtree in write, *and*
they could be the same one.

The only one off-hand is "bzr merge --uncommitted" which would use 2
working trees. But I think "bzr merge --uncommitted ." is a user error.

I'll be looking into it today.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF8DtzJdeBCYSNAAMRAjcQAKDTbzAHl7GR6Zq3J4IOXD5PzD8JzQCeLlG8
GUMf/3Nbvt5ioQe5nlUKpPM=
=b0Md
-----END PGP SIGNATURE-----