[Critical] dirstate format use OS file locking

[John Arbash Meinel]

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

John Whitley wrote:
> Robert Collins wrote:
>> (When taking a read lock, we can read the crc32 at the top, if its the
>> same,
>> keep buffered and partial state if not, flush our state for the tree.)
> [...]
>> So on windows, you cannot replace an in-use file, and this very scenario
>> has the file in-use.
> 
> How are the read locks being taken (e.g. what methods in bzrlib and/or
> Python lib?  I'll RTFS down from there..)  It may be possible with some
> jiggery-pokery (appropriate sharing flags on open and/or locking
> mechanisms) to make this work as desired on Windows.  If someone can
> point me in the right general direction in the code, I'll go off and do
> some footwork to see if my ideas on this have any merit.
> 
> -- John

No, it really shouldn't be working on Linux.

The specific code is in bzrlib/lock.py

But the effect is that we take out an OS lock on .bzr/checkout/dirstate.

What is happening is that our fcntl locks don't care if the current
process has already locked the file. While on Windows locking the same
file 2 times in the same process is an error. (Well you can do 2 shared
locks, but you can't do a shared lock and an exclusive lock).

The problem is that until now, read-locks were actually a no-op, because
of how we wrote our data, we wouldn't disturb things in place. However
for the .bzr/checkout/dirstate file, we *want* to be able to overwrite
it / modify entries for peformance reasons. So having it change while we
are reading is a "Bad Thing".

I'm happy to have your help on the subject, but my feeling is that it is
other code paths that relied on the no-op status of read-locks.

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

iD4DBQFF8JfxJdeBCYSNAAMRAkwvAJi9/ubfN1jjhqjlt5H3ZAYY/FFOAJ40GUkM
aauYltmCJ/7bff/qimSB6Q==
=NngB
-----END PGP SIGNATURE-----