Quote:
Originally Posted by tshering
When nickel is started from KSM, there are still some scripts running that are located on the user partition (and in many cases instances of fmon). That being the case, the user partition cannot be unmounted when nickel connects via usb. This is not pretty, and becomes dangerous if files are modified that are currently in use (the database)
|
So you are talking about the first case?
But I would whether think the user partition is umount successfully (maybe forced, regardless of opened database) because the device entered the "slave mode" after all.
This explains the behaviour I've mentioned in #19:
Quote:
1. install fmon (or uncomment the on_start.sh & reboot) ->
2. connect and transfer with calibre (success or communication error, database malformed) ->
3. disconnected, content processed (or not), books and shelves disappear ->
4. comment out on_start.sh and reboot ->
5. broken items still broken, but newly transferred items shows normally.
|
Which means the database has been damaged sometimes during the `umount -f` process.
If this is true, maybe adding a script that kills/re-spawns all fmon processes then make it triggered by an udev rule will solve the problem.
But what about the second case? Someone with shell access of the device can try my setup and lsof the user partition after koreader has brought nickel back. :/
Or, I'll do it in /etc/init.d/rcS if my database get ruined again. :P