Jon, please read what I wrote! The -wal and -shm files are
normally present when the databases are open since the database are opened in journaled mode. You would need to hook into the USB connection process after the database close code for information about the database close state to be meaningful. Looking at the .kobo directory using ssh or telnet will show the -wal and -shm files are present. The size of them is somewhat important since larger files will take longer to merge into the database during the database close which is why I suspect that the reboot keeps the database corruption error message from happening.
So you check from the home screen. The databases will be open in journaled mode. The -wal and -shm files will be present and your logic says to reboot.
Here's a look at the .kobo directory on my Sage over the network:
Code:
kobo login: admin
Password:
login: can't change directory to '/home/admin'
[root@kobo ~]# cd /mnt/onboard/.kobo
[root@kobo .kobo]# ls -al
total 283024
drwxr-xr-x 17 root root 16384 Jan 24 20:58 .
drwxr-xr-x 13 root root 16384 Dec 31 1969 ..
-rwxr-xr-x 1 root root 1061888 Jan 24 20:57 BookReader.sqlite
-rwxr-xr-x 1 root root 32768 Jan 25 15:08 BookReader.sqlite-shm
-rwxr-xr-x 1 root root 85968 Jan 25 15:08 BookReader.sqlite-wal
-rwxr-xr-x 1 root root 287318016 Jan 24 12:57 KoboReader.sqlite
-rwxr-xr-x 1 root root 32768 Jan 25 15:08 KoboReader.sqlite-shm
-rwxr-xr-x 1 root root 876160 Jan 25 15:08 KoboReader.sqlite-wal
[root@kobo .kobo]#
Database files after a restart:
Code:
-rwxr-xr-x 1 root root 1062912 Jan 25 2025 BookReader.sqlite
-rwxr-xr-x 1 root root 32768 Jan 25 15:19 BookReader.sqlite-shm
-rwxr-xr-x 1 root root 0 Jan 25 15:19 BookReader.sqlite-wal
-rwxr-xr-x 1 root root 287362048 Jan 25 2025 KoboReader.sqlite
-rwxr-xr-x 1 root root 32768 Jan 25 15:19 KoboReader.sqlite-shm
-rwxr-xr-x 1 root root 8416 Jan 25 15:19 KoboReader.sqlite-wal