[Critical] dirstate format use OS file locking
John Arbash Meinel
john at arbash-meinel.com
Thu Mar 8 23:10:41 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
John Whitley wrote:
> Robert Collins wrote:
>> (When taking a read lock, we can read the crc32 at the top, if its the
>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar