How to open file with exclusive lock?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Jul 12, 2016 at 03:40:36PM -0700, Charles Hixson via Digitalmars-d-learn wrote:
[...]
> OK.  It's not possible without OS support.  Agreed.  And I don't want
> to get into C calls, but rather to use the mechanisms that D provides.
> And this *probably* won't cause any problems.  But how should I tell D
> that that's the way I want to access to work?  It's not clear to me
> that locking beyond the current EOF is valid, or whether it will
> decide that it needs to reserve the space before I use it (in which
> case locking from 0->ulong.max bytes is a bad idea, and would totally
> fill my hard disk).

Here's another approach.

Since it's almost a given that we're talking about cooperating processes
sharing an advisory lock here (since a global mandatory file lock seems
to have poor support, at least on Posix), we don't *have* to lock the
actual bytes we're writing to. We can simply reserve a couple of bytes
(perhaps even just one byte) at the beginning of the file, and agree
among all processes that we will always try to acquire lock on that byte
before writing to (the rest of) the file.  Essentially it would serve as
a file equivalent of a mutex.  Then wrap all your file primitives in a
little wrapper that acquires this mutex before performing file I/O, have
your program only do I/O through this wrapper, and you're all set.

(IIRC, this is how the SQLite3 library implements database read/write
locks. Each sqlite3 database file has a few bytes, IIRC 6 bytes, at a
known file offset, that it uses to control various levels of access to
the database. Depending on which level of locking was needed, it would
acquire a lock on one or more of these bytes, before accessing the rest
of the file. It doesn't actually acquire a lock on the bytes being read
/ modified.)


T

-- 
If you're not part of the solution, you're part of the precipitate.