Alas, it's nowhere near so simple. There will be other processes that
*can* be writing the file at the same time, so we still need an
advisory locking mechanism.
In case you were wondering, we're trying to implement row-level
access control (using views and triggering write operations through
an external server) via filesystem MAC mechanisms on an EAL-5 secure
operating system (STOP OS). Hence the headaches.
-Mike Ashmore
On May 19, 2006, at 10:32 AM, [EMAIL PROTECTED] wrote:
Mike Ashmore <[EMAIL PROTECTED]> wrote:
Hello all,
I'm working on a system in which I'm using SQLite to open a number of
database files and to perform operations on aggregate views of those
files.
The problem I've got is, some of the files I want SQLite to open and
SELECT from, I can only acquire read access to. And the operating
system I'm using doesn't allow me to place any sort of advisory lock
on a file that I've only got read access to (it considers placing an
advisory lock to be a write operation) (@#%!# high security operating
systems).
If the file truely is read-only (that is to say, if you know
no other process is going to be changing it out from under you)
then you can just do this:
PRAGMA omit_readlock=ON;
With this option enabled, SQLite will not bother to use a
read-lock on readonly files.
If I recall, though, the file really does need to be readonly
for this to work. So "chmod 444" the file first.
--
D. Richard Hipp <[EMAIL PROTECTED]>
