"attempt to write a readonly database" after upgrading from 4.5.4 to 4.6.0

SQLCipher
1

I recently upgraded from 4.5.4 and have noticed some curious exceptions (only a few, but still significant) that were not happening before:

android.database.sqlite.SQLiteReadOnlyDatabaseException: attempt to write a readonly database (code 1032)
       at net.zetetic.database.sqlcipher.SQLiteConnection.nativeExecuteForChangedRowCount(SQLiteConnection.java)
       at net.zetetic.database.sqlcipher.SQLiteConnection.executeForChangedRowCount(SQLiteConnection.java:818)
       at net.zetetic.database.sqlcipher.SQLiteSession.executeForChangedRowCount(SQLiteSession.java:758)
       at net.zetetic.database.sqlcipher.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:90)
       at net.zetetic.database.sqlcipher.SQLiteDatabase.executeSql(SQLiteDatabase.java:1992)
       at net.zetetic.database.sqlcipher.SQLiteDatabase.execSQL(SQLiteDatabase.java:1900)

The old code was running for years with tens of thousands of active installs, without this issue.

Other than migration essentials, nothing else has changed in my code, so it seems that it’s some subtle change in behavior. Any ideas?

Note: for SQLCipherOpenHelper.openDatabase() I’m using defaults for readOnly=false and enableWriteAheadLogging=false

2

Hi @marcardar,

Thanks for reaching out regarding SQLCipher. The specific error code you’re receiving is 1032, which maps to SQLITE_READONLY_DBMOVED [1]. This indicates that your database file has moved since it was opened and any attempt to modify the database could result in a corruption. For the scenarios where this error is occurring within your application, is your application moving or renaming database files?

  1. Result and Error Codes ↩︎

3

Thanks Nick, that helps a lot. In my app, on first time install, I open the database in writable mode to build some indexes, and then when done, turn off WAL, close, and then move it to a new location where it would be opened later in read only mode. So my best guess is a case where two threads are trying to do that at the same time, so one thread moves the database while the other still working on it. I will make the thread safety more robust in case it is that. Is there anything in recent updates that might make such multi-threaded access behave differently?

4

Hi @marcardar,

No, there are not any specific recent changes to SQLCipher/SQLite regarding thread safety. Please let us know if you continue to run into unexpected behaviors.