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).
Since modifying the OS isn't an option, the next step would appear to
be to write some sort of external lock-management server, and have
SQLite redirect all of its fcntl(F_SETLK / F_GETLK) operations to
that server. I was wondering if anybody has done anything like this,
and if perhaps someone could offer some tips on how I might go about it.
Clearly I'm going to have to pass the server the "op" and "struct
fcntl" arguments from what originally was the fcntl call. But since
the lock server will be a separate process, the file descriptor from
my sqlite process doesn't seem terribly helpful in identifying what
file I'm trying to lock. Looking through os_unix.c, I see numerous
semi-inscrutable references to keeping track of inodes, etc; perhaps
the inodes are the unique file references (as opposed to other
process's file descriptors) my lock server should be keeping track of
as well? Won't a given database file span quite a few inodes?
Since locking will require me to invoke (slow) IPC mechanisms, I
don't want to send any more lock messages off to my lock server than
absolutely necessary; any suggestions on how I should approach that?
Thanks in advance for any help you folks can offer on this problem.
-Mike Ashmore
