[sqlite] sqlite3 command line, read-only
On Tue, Apr 26, 2016 at 10:56 PM, J Decker wrote: > https://www.sqlite.org/wal.html > > "5. It is not possible to open read-only WAL databases. The opening > process must have write privileges for "-shm" wal-index shared memory > file associated with the database, if that file exists, or else write > access on the directory containing the database file if the "-shm" > file does not exist." > > second, I'm pretty sure that WAL mode is written to the database, so > it remembers what journal mode it was using... which if it wasn't WAL > would require writing to the database. more from wal.html "Persistence of WAL mode Unlike the other journaling modes, PRAGMA journal_mode=WAL is persistent. If a process sets WAL mode, then closes and reopens the database, the database will come back in WAL mode. In contrast, if a process sets (for example) PRAGMA journal_mode=TRUNCATE and then closes and reopens the database will come back up in the default rollback mode of DELETE rather than the previous TRUNCATE setting. The persistence of WAL mode means that applications can be converted to using SQLite in WAL mode without making any changes to the application itself. One has merely to run "PRAGMA journal_mode=WAL;" on the database file(s) using the command-line shell or other utility, then restart the application. The WAL journal mode will be set on all connections to the same database file if it is set on any one connection."
[sqlite] sqlite3 command line, read-only
https://www.sqlite.org/wal.html "5. It is not possible to open read-only WAL databases. The opening process must have write privileges for "-shm" wal-index shared memory file associated with the database, if that file exists, or else write access on the directory containing the database file if the "-shm" file does not exist." second, I'm pretty sure that WAL mode is written to the database, so it remembers what journal mode it was using... which if it wasn't WAL would require writing to the database.
[sqlite] sqlite3 command line, read-only
On Apr 26, 2016 8:16 PM, "Mark Foley" wrote:
>
> I'm back with more read-only issues.
>
> Thanks to postings on this list, I've made progress, but still more
issues.
>
> Using the sqlite3 command-line, I'm attempted to open,
> read-only, a database located on a Windows 7 workstations, from a Linux
server.
> I am mounting the Windows volume r/o:
>
> mount //${workstation}/C /mnt/iCal -o ro
>
> I am opening the database read-only, with timeout:
>
> $ sqlite3 -separator '~' -cmd ".timeout 2"
"file:/mnt/tmp/Users.../calendar-date/local.sqlite?mode=ro"
>
> So, why do I occasionally get these Error messages in my logfile?
>
> 2016-04-26 14:32 HPRS_Office_Calendar_Calendar.ics updated
> Error: attempt to write a readonly database
> Error: attempt to write a readonly database
> Error: attempt to write a readonly database
> Error: attempt to write a readonly database
> Error: attempt to write a readonly database
> 2016-04-26 14:52 HPRS_Office_Calendar_Calendar.ics updated
>
> First of all, why is it attempting to write anything if it's opened
read-only?
>
> Secondly, how could it ever succeed if the entire volume is read-only?
Note that
> there were no errors on the 1st and last examples. And, the "updated"
message
> refers to the output of the cron script, not an update to the database.
Is there a hot journal file with the database? If so it may need to roll
back a transaction which will require write access anyway.
[sqlite] sqlite3 command line, read-only
I'm back with more read-only issues.
Thanks to postings on this list, I've made progress, but still more issues.
Using the sqlite3 command-line, I'm attempted to open,
read-only, a database located on a Windows 7 workstations, from a Linux server.
I am mounting the Windows volume r/o:
mount //${workstation}/C /mnt/iCal -o ro
I am opening the database read-only, with timeout:
$ sqlite3 -separator '~' -cmd ".timeout 2"
"file:/mnt/tmp/Users.../calendar-date/local.sqlite?mode=ro"
So, why do I occasionally get these Error messages in my logfile?
2016-04-26 14:32 HPRS_Office_Calendar_Calendar.ics updated
Error: attempt to write a readonly database
Error: attempt to write a readonly database
Error: attempt to write a readonly database
Error: attempt to write a readonly database
Error: attempt to write a readonly database
2016-04-26 14:52 HPRS_Office_Calendar_Calendar.ics updated
First of all, why is it attempting to write anything if it's opened read-only?
Secondly, how could it ever succeed if the entire volume is read-only? Note that
there were no errors on the 1st and last examples. And, the "updated" message
refers to the output of the cron script, not an update to the database.
THX --Mark
[sqlite] SQLite SEE with FIPS compliant Encryption?
On 4/26/16, Mike Nicolino wrote: > Hello Everyone, > > We're using SQLite SEE to encrypt our databases and I was wondering if there > is a version of SEE that is FIPS compliant/certificated? If you will read FIPS 140-2, you will find that it has many requirements that are outside the purview of SQLite and SEE (and SQLCypher) - things such as tamper resistance and detection, key management, process isolation, etc. FIPS 140-2 is a system-level specification. But SEE is not a system. SEE is a component part. Hence, it makes no sense to talk about SQLite and/or SEE being FIPS 140-2 compliant/certified. Asking for FIPS 140-2 compliance/certification for SQLite/SEE is like asking for the IIHS crash test rating for your in-dash navigation system. In-dash navigation systems do not have crash test ratings. Crash test ratings only apply to complete cars. SEE uses AES which is an FIPS 140-2 compliant algorithm. So SEE can be used within FIPS 140-2 compliant/certified systems. > > I'm considering a local modification to SEE to have it call the Windows APIs > rather that doing its own encryption; has anyone tried such a thing before? > The cccrypt version of SEE calls the built-in CCCrypt libraries on Mac/iOS. You can probably adapt that code to invoke whatever Windows APIs you like. Note that CCCrypt uses AES just like the default SEE module. So they are completely interoperable. You can encrypt with one and decrypt with the other. If you manage your port to Windows correctly, you can probably achieve portability there as well. -- D. Richard Hipp drh at sqlite.org
[sqlite] No datasize field - why?
Scott wrote: >It depends on what you call a character. If you consider a "character" the >same way most people do (one typographical unit), then you have to deal >with varying numbers of code points per character, even in a "fixed width" >encoding like UTF-32. There is no hard limit on how many combining marks >can be appended to a base code point. >See >http://stackoverflow.com/questions/10414864/whats-up-with-these-unicode-combining-characters-and-how-can-we-filter-them >for a stupid / extreme example. -- UTF-* using sometimes a multiple 8 bits for a character. In the past as few as five ( e.g. https://en.wikipedia.org/wiki/Baudot_code ). Around the seventies six old Bull (e,g, GE 400-series' GBCD) resp. eight IBM (EBCDIC). ASCII started with seven plus a bit for parity checking. As always: YMMV. One may use this knowledge for encrypting I guess. Kind regards/Vriendelijke groeten. Klaas `Z4us` Van B., CEO/CIO LI#437429414
