Feature request: make storage location customisable or add support for cloud storage

[buerki]

It would be very useful to be able to change the storage location of ebooks, for example to a cloud synced volume so that the library can be accessed from more than one computer. Or even better, if a standard like WebDAV could be added as a storage location.

Many thanks

[llemeurfr]

Another request of the same kind:

Hi I'm looking a way to modify the publications folder.
It has become really big and I want to move it to an external ssd drive.
I do not find a way to modify this even in the registry. Is there a way to do it?

[llemeurfr]

A reference is Calibre: https://blog.calibre-ebook.com/how-to-backup-move-and-export-your-library-in-calibre/

[danielweck]

For expert / technical users, there is a workaround to "externalise" the publications folder: filesystem symbolic linking.

For example on MacOS (and I assume Linux too):

ln -s SOURCE DESTINATION where SOURCE = /Users/username/Desktop/publications (for example, if the user wants to store their local bookshelf on the "desktop") and DEST = /Users/username/Library/Application Support/EDRLab.ThoriumReader/publications which is the default filesystem location for imported publications (or /publications-dev for unreleased, non-production Thorium builds). Note that MacOS "Make Alias" command in the Finder context menu does not work.

Naturally, this technique is for advanced users only, as command line mistakes are easily made, which can result in corrupting Thorium's database. Notably: the DESTINATION folder in the ln -s command must not exist, it must first be moved out to the SOURCE location, and of course filesystem permissions can affect what files Thorium is allowed to access (depending on system-level "users" configuration).

Regarless of how user-friendly the method is, there are significant caveats which is why I would personally be reluctant to offer this feature in the first place:

Separating the publication assets from Thorium's internal database gives users a false impression that manually adding/removing files to/from the "externalised" publications folder will work. It will not, it will break things. Thorium automatically discards entries from the publications database when their corresponding assets fail to load. Consequently, if the user makes a mistake when creating the symbolic link, or if they manually edit the contents of the "externalised" publications folder in such a way that the files cannot be found when Thorium starts, then the application's internal database will be updated to remove the offending entries, resulting in loss of data in the user interface. The files remain on the filesystem, but because they are contained in folders named with UUID alphanumerical characters, they will be hard to find. In fact, even if they are found and re-imported, all settings associated with the newly-imported publications are reset to their initial state (i.e. no bookmarks, display configuration, etc.). Plus, unless the user moved the orphan UUID folder out of the "externalised" publication folder, there will be duplicates because Thorium creates a fresh UUID folder for any newly-imported publication. Furthermore, certain publication types such as PDF and DAISY are transformed before they are actually imported into Thorium's database and physical filesystem store, so the resulting .webpub assets do not correspond exactly to the user's original files.

An alternative option that could deter users from fiddling with the files manually would be to "externalise" not only the publications folder, but Thorium's entire database system (and possibly other Electron-specific files that are normally stored in /Users/username/Library/Application Support/EDRLab.ThoriumReader/ (MacOS) or the equivalent default filesystem location on Linux and Windows (e.g. C:\Users\username\AppData\Roaming ... although IIRC this depends on whether Thorium is installed from the Windows Store or from the NSIS installer). I think this would open another can of worms though, as we would be touching on the lower-level organisation of an Electron app.

[danielweck]

@panaC in preparation for such "externalised" storage feature which would give Thorium users more flexibility, we would at the very least need to relax the current logic which automatically prunes the database when publication resources fail to load / cannot be found. For example, we could implement a special "flag" that would identify broken bookshelf entries when Thorium starts, and "move" them (logically, not physically) to a lower user interface strip (category in the library view), and highlight them in red or some other "failure" indicator.
This would allow detachable USB storage units or network mounts.

[llemeurfr]

Calibre may offer a good reference on that:

• one can move the storage folder (the internal format is kept as-is, the move works only if there is sufficient free volume at the destination).
• one can export all publications (in such a case, the storage folder is not modified, copies are made).

In the export case, because we modify some publications (DAISY), we can admit that the exported format is our internal format, or we can work on a reconstruction of the original format. It's our call but it is independent from the core export feature.

[danielweck]

Moving this to a "discussion", as the issue is currently not actionable (details need to be fleshed out).

[gautierchomel]

Related question in the documentation repo : edrlab/thorium-reader-doc#11

[gautierchomel]

A first simple step could be Export all publications.

[llemeurfr]

True, but this is still a duplication of content for those who simply need a source for a backup, or a cloud storage for accessing a catalog of ebooks from multiple reading systems.
A Daniel said, one of the biggest issue is the database, which is totally tied to the catalog of publications.