Where is the LOCAL collection setup info stored on the device?

[Antinoos]

I've learned from the following post https://www.mobileread.com/forums/sh...php?t=292382#3 how to apply a fake registration to a jailbroken PW3 (and KT3, too) that is only used offline (in airplane mode).
BTW: A really cool feature! - @knc1, what a great tip!

The fake registration opens the door to create and manage local collections. Interesting feature for me, as I've roundabout 1000 books/documents stored on my device... Thus I created 10 different collections - locally only, as mentioned. Works perfect. Feels really like a new device now: Much more clarity in the library view possible.

But here starts my problem: Where is the informaton about the local collections setup stored? I didn't find any traces in the user visible storage, not even in /mnt/us/system/ ...

I ask this question as I want to backup my current collection setup besides the documents themselves, thus being able to restore all of them to a replacement Kindle without needing an Amazon account and/or the cloud.

Any suggestions are welcome! and in advance!

[hius07]

Look at
https://www.mobileread.com/forums/sh...d.php?t=160855

[Antinoos]

Didn't find it via a forum search.

So, the only thing I have to do, is copying the file /var/local/cc.db to a safe place. If needed, I may restore it to another Kindle with the same fw version and content of the documents folder at the point of time I've saved the mentioned database file? (IOW: make a full backup of /mnt/us/ and additionally save /var/local/cc.db?) No other files from e.g. /var/local/* needed?

[knc1]

You might need some of the other database files, but cc.db is the main one.
If librariansync is working for you, then whatever it does to the database system is what you want to keep.

It need not be firmware specific - just back up a complete dump of the database.

cd /var/local
sqlite3 cc.db .dump >/mnt/us/collections.sql

(that is a period in front of 'dump').
collections.sql is a script file to create a new database with:

cd /var/local
sqlite3 my.db </mnt/us/collections.sql

similarly with all other *.db files in /var/local
then read them and tell us which ones are related to the other ones.

Those would make a good couple of examples for the runme thread.

See also:
http://www.sqlitetutorial.net/sqlite-dump/

or a runme script to schedule a regular running of a script to backup the database files with cron/at
maybe once a week?

[Antinoos]

... ugh ...

Sorry, though I've got al lot of computer experience, this sounds a bit too difficult for me to get, install and then burrow into the needed tools.

Why isn't it possible to just transfer some (or even better: only one) file(s) to another device that contains all information about collections?

And what the hell let Amazon/Lab126 decide that on the one hand the very low level search indices reside inside the /system/ subdirectory in the user visible store (next to the /documents/ folder); while on the other hand the collections db (also directly related to the local documents!) does not?!?

Really confused.

Okay, fonund my very individual way to avoid any risks to destroy needed db structures: Have made sceenshots of the contents in each collection - these make it much easier to gather up all the needed books from my very, very long library list a bit more quickly than the first creation of the collections (this took me a few hours of really focused work, that's why I wanted to have a backup handy, like I have one of my documents folder of course...)

[knc1]

You do not have to install anything, sqlite3 is pre-installed.
Just get command line access and type the two commands as shown.

The collection('s) data base is in the user's persistent storage (/var/local) because it needs to stay in sync with the (similar) data base in the user's account on the Amazon server(s).
There is no telling what might go wrong if the user could diddle the contents from visible user storage.

The only technical thing to do to turn those two examples into runme.sh scripts is make the first line read:

#!/bin/sh

And of course, name it correctly (basename upper case and extension lower case).

[Antinoos]

Seems that I've just forgotten that the Kindle is basically a tiny Linux computer; and jailbreaking gives - at least basic - access to it, like rooting does with an Android device.

My problem also has to do with the fact, that via USB only the userspace /mnt/us/* is visible and thus can be inspected, copied and managed directly. And therefore I didn't know which basic Linux tools are actually preinstalled.

Well, I have console access (via Vlasoftsoft's cool launcher - I also used the filemanager from this collection to inspect the /var/* stuff), I'll give it a try. Thanks again.

[knc1]

I just tried it on a PW3 running 5.9.2 and it worked just as expected.

[Antinoos]

You mean that the above scripts allow to backup and restore the local collection database in the case it was corrupted or reset/deleted?

[knc1]

Originally Posted by Antinoos

You mean that the above scripts allow to backup and restore the local collection database in the case it was corrupted or reset/deleted?

For cc.db, to and from standardized sql text files.
So you can port it between firmware versions, and even run it on your IBM mainframe (if you have DB2 installed on it).

I have not had the time to discover if that is the only database file you have to save to preserve your collections.
5.9.2 made a lot of changes and they might have involved more than this one file.

But the principle remains the same, only the *.db name changes for the others.

I thought that is what you wanted.

[Antinoos]

As stated in my OP, there's no need for porting the cc.db between different fw versions, but between different devices of the same type (or possibly between a PW3 and KT3), running all the very same fw, and containing an identical library.

And as you can read from my profile, I'm using 5.8.11 and will never ever update to the nasty 5.9.2...

[knc1]

Originally Posted by Antinoos

As stated in my OP, there's no need for porting the cc.db between different fw versions, but between different devices of the same type (or possibly between a PW3 and KT3), running all the very same fw, and containing an identical library.

And as you can read from my profile, I'm using 5.8.11 and will never ever update to the nasty 5.9.2...

5.9.2 is what I had to test on.
I know you are using 5.8.11, that is why I said for you to check for yourself.

Sorry, but the inventors of SQL standardized on a portable text file based backup and restore.
Not my fault that the format is more portable than your use case requires.

Maybe you could find some proprietary tool that does backup and restore to an obfuscated binary file format (search: MS?, Lab126?) that you can not use a text editor on.

[Antinoos]

Thank you for your efforts and help. The crucial piece of information in my case really was the filename /var/local/cc.db only.

What worked perfectly for me, step by step, working locally with the device only, using the file manager from Vlasoftssoft's toolbox (freeware part of his otherwise shareware PBChess package):
1) On the "master device" (with reference collection configuration), copy /var/local/cc.db to /mnt/us/
2) Transfer this file to the other Kindle with exactly the same fw version and the same library content using USB connection via an external PC. Let's say to /mnt/us/ (root of user storage).
3) On the second Kindle, rename /var/local/cc.db to /var/local/cc.db.old (just to have a backup, this step is not really necessary...).
4) On the same Kindle, copy /mnt/us/cc.db to /var/local/cc.db
5) Immediately restart this Kindle. The duplicated collections now all are there.

[Antinoos]

To make it a bit more detailed: This even worked cross-platform (tested with PW3 and KT3, both running fw 5.8.11). Unfortunately, the content of the documents folder isn't exactly the same on both devices.

All my private documents are the same on both Kindles, but the only "truly Amazon" book differs in name and contents: the Users Guide. This allowed me to check what happens then. Of course, when selecting this entry in the respective collection on the "wrong" Kindle, an error occurs: "This book isn't on the device." Removing this entry from the collection and immediately re-adding it, doesn't help. Same error. I had to completely delete the book from the device and sideload it from a backup after a restart of the Kindle. Then it could be added to the respective collection and was usable again.

Gesendet von meinem Google Pixel mit Yabba-Dabba-Talk.

[knc1]

update the asin for it in cc.db