- Jul 26, 2020
- San Francisco
- Lightroom Experience
- Lightroom Version
I used several tools (watch, inotifywait, wireshark) to observe catalog operations while having LR sync develop settings across >3K photos:Other factors are: (1) Lightroom now accesses the catalog in SQLite WAL (Write-Ahead Log) mode: changes are written to a .wal file and later applied to the .lrcat catalog file. ... SQLite provides a function to flush changes to storage. I don't know if Lightroom uses it, and if it actually causes the changes to be written all the way back to the server.
- Windows does set oplocks on the .lrcat* files, enabling client caching.
- Data is frequently flushed to the .lrcat-wal file on the server.
- Occasionally, SQLite checkpoint operations apply the WAL data to the .lrcat file on the server.
- Other than the initial oplocks, no other lock requests are sent to the server. (According to the documentation, WAL mode limits database access to the (Lightroom, in this case) processes on a single PC, and these processes coordinate through shared memory.)
- SQLite also creates a shared memory-mapped file (.lrcat-shm) in the catalog folder. According to the documentation, this file contains no persistent content and is not used for recovery.
- SQLite creates temporary files, but none were observed in the catalog folder, so I presume that they're in a temp folder on a local drive.
This is all good behavior. Since "one test is worth a thousand expert opinions", it would be interesting to force Windows to crash (see notmyfault) while LR is performing various catalog modifications to measure the relative risk of corruption with the catalog on a network drive vs. a local drive. I suspect it's negligible.