In testing the latest SQLite snapshot with WAL enabled, it seems that there's no way to use a database in a read-only location. For example, let's say I've created a database as root, then closed it (cleanly):
$ ls -l /flash/alarms.db* -rw-r--r-- 1 root root 36864 Jan 1 00:14 /flash/alarms.db If I try as another user to use that database, I get an error: $ sqlite3 /flash/alarms.db SQLite version 3.7.0 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> PRAGMA journal_mode; Error: unable to open database file sqlite> However, if I create a symlink to that database in a location that I have write access to, then everything works fine: $ ln -s /flash/alarms.db ./alarms.db $ ls -l alarms.db* lrwxrwxrwx 1 admin admin 16 Jan 1 00:15 alarms.db -> /flash/alarms.db $ sqlite3 alarms.db SQLite version 3.7.0 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> PRAGMA journal_mode; wal sqlite> .quit $ ls -l alarms.db* lrwxrwxrwx 1 admin admin 16 Jan 1 00:15 alarms.db -> /flash/alarms.db -rw-r--r-- 1 admin admin 32768 Jan 1 00:15 alarms.db-shm -rw-r--r-- 1 admin admin 0 Jan 1 00:15 alarms.db-wal So clearly this is a side-effect of WAL creation, which happens in the same directory as the database file. This doesn't seem like it should fundamentally be any different than normal journaling mode, in that opening a database in read-only mode makes the creation of a journal / WAL unnecessary. But I'm not familiar with the WAL internals, so maybe there's more to it. FYI, this works fine with normal journaling mode (we bumped in existing code after changing the journal_mode). Any additional flags or ways of doing this that I'm missing? Or is it a bug? Thanks! -- Matthew L. Creech _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
