File locking

[Martin Pool]

On 9/8/07, Lukáš Lalinský <lalinsky at gmail.com> wrote:
> Hi,
>
> I'm trying to fix the Windows file locking issues, but after playing
> with it a little I'm starting to think that's the fcntl locking
> implementation the one that is wrong and that there are some serious
> locking issues inside bzrlib. If I understand it correctly, acquiring
> read lock on a file, while write lock is held, should fail, because the
> process would be then allowed to read file in inconsistent state. But if
> I do this on Linux, I get no errors:

As Alexander says, this is because with file locks on Unix a process
cannot exclude itself.

For current repository and branch formats we use LockDirs.  These
don't rely on OS locks
and work across all transports.  There is no 'read lock' - the thing
they protect has to be safe for readers to see at any time, which is
the only sensible design for publishing over dumb transports.  You can
get stale locks if the holder disappears abruptly.  Although there are
some things we could do to make the UI better when contention or stale
locks occur I would say they basically work pretty well.

The dirstate file used in current working trees does use an os file
lock.  This is because we contemplated updating the file in place, in
other words rewriting just part of that.  That would be difficult to
do correctly if other people were reading the file, so we used
read/write locks.  I don't think we actually make use of this at the
moment.

I'm not so happy with this design because it locks out readers when
there's no logical reason why they're excluded, causes problems on old
windows releases, and uses a less-portable design and interface.
There have been a few threads about how to fix this which you should
be able to find in the archives.  In general the approaches seem to
be:

* stay like this, or maybe just change the details of the locking approach
* update by writing a new file then renaming over the top; on Windows
the process trying to rename will need to block and wait until readers
have closed the file and it's allowed to proceed
* update in place, but use a file format that will allow the readers
to cope, either by detecting the change or making the change atomic to
the readers,

-- 
Martin