On Sun, 16 Dec 2018 at 05:00, Pierre Tempel wrote:
> > “... programs which rely on [the O_CREAT and O_EXCL flags of
> > open(2) to work on filesystems accessed via NFS version 2] for
> > performing locking tasks will contain a race condition. The solution
> > for performing atomic file locking
The only way I can think of to have a large counter in a lock is to lock
access to a file containing a counter and I don't know if not-a-file-system
semantics support that.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
It might be worth investigating some other projects that use lock
files. Git, as mentioned locks the index with a lock file, but AFAIK
without counting. As a reference for the NFS issue, see
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html
section 7.11.2.1, which
On 12/15/18, Pierre Tempel wrote:
>
> Hm. Doesn't this mean the proposed solution still works, but with
> directories instead of files for the sake of atomicity? I.e. for each
> lock type, create a unique dir name (e.g. ".1.lock") and stat for all
> lock types when changing levels?
I think you
No. Unfortunately, if all you have is the presence or absence of a
directory to determine if the file is locked, then that is only one
bit of information. And there is no way to encode all the other
locking states in a single bit.
Hm. Doesn't this mean the proposed solution still works, but
On 12/15/18, Pierre Tempel wrote:
>
> First, dot-file actually uses a directory, however, the comments don't seem
> to give a reason for this. Why is a directory created, instead of a more
> (arguably) traditional lock file (see e.g. git)? dotlockLock creates the
> directory with permissions set
Hi,
I'm currently working with a system where dot-file is the only applicable
SQLITE_ENABLE_LOCKING_STYLE and I'm trying to understand how this is
implemented exactly. So I've read through the implementation of this
locking strategy and a few questions came to mind:
First, dot-file actually uses
7 matches
Mail list logo