obok: linux: improve Kobo Desktop directory searching

[cyphar]

The Kobo Desktop program will (when running under Wine on Linux) put all
of its data in the current working directory. This means that there
may be more than one Kobo.sqlite floating around by the user, which
leads to Obok showing an outdated list of books and the user being
confused by Obok cannot find the full list of books.

Solving this completely appears to be a bit too complicated, so this
patch is a best-effort improvement for the worst cases which can be
caused by this:

1. If the user deletes the files but Obok has already cached the path,
   previously Obok would just error out rather than trying to search
   for a new Kobo.sqlite path and updating the cache.

2. We search $HOME before searching /, which speeds up initial usage of
   Obok in the common case (usually Kobo Desktop will be installed in
   ~/.wine/drive_c) and also ensures that we correctly preference the
   current user's Kobo Desktop installation.

Signed-off-by: Aleksa Sarai [email protected]

[cyphar]

I moved this into ~/.config/calibre/plugins/obok since that better matches the internal calibre configuration paths than just dumping it in ~/.config/calibre. Users upgrading shouldn't notice a huge difference (thanks to the $HOME optimisation, the first search will be fairly quick) though in theory (since there might be multiple Kobo.sqlite files on their machine) this might change which Kobo data directory is used.

[cyphar]

One possible solution would be to look at the last-touched Kobo.sqlite file. However this would cause issues with our caching -- even if we stored all paths found in the cache, the user might accidentally create a new one (because they don't notice Kobo Desktop's incredibly strange behaviour). So we wouldn't be able to cache them.

The other option would be to look at whether there is a running wine Kobo.exe program and then use its /proc/self/cwd path but that has a whole host of other issues.

[noDRM]

I am not familiar with the Kobo Desktop application, but to me, both the old and the new implementation sound like a very bad idea. In the worst case, this will walk through the whole HOME directory, and then again walk through /, including home. That's going to take a loooong time, and it might still pick the wrong file.

Looking at the Windows code, the Kobo app seems to use a subfolder of %LOCALAPPDATA% or %USERPROFILE%. Given that the Obok plugin settings window seems to already contain a way to override this Kobo directory parameter, I would say it should be enough to assume that the Wine directory is either $HOME/.wine or $WINEPREFIX (if set), and if the code can't find Kobo data in either directory, it should rely on the user manually setting the Wine path in the settings.

At least that's how it's currently done with the main DeDRM plugin (there's a WINEPREFIX input field in the settings for Linux users where they can enter the path to their Wine prefix if it's not $HOME/.wine). That seems to be a better solution than scanning the whole / drive just to try and find the directory ...

Or am I misunderstanding how the Obok plugin works?

[cyphar]

I agree having it be configurable would be better, I was just trying to fix a series of bugs in the old implementation (and searching $HOME is much faster than always searching / first) and wasn't sure how many changes you'd be happy with.

The issue is that (I believe this is a bug in the Kobo desktop application) on Linux, the Kobo Reader will always use the current directory as the place to dump all of the Kobo data files. I think this is only the case on Linux. This means if you run Kobo in $HOME (or any directory not in $WINEPREFIX) then the files won't be in $WINEPREFIX. I'm not sure there's a nice solution for this other than to just get the user to select a directory themselves. But scanning $HOME (or maybe first $HOME/.wine and then $HOME) is probably going to be necessary so that users can have Obok "just work".

[noDRM]

Are you sure that that is the case? I've just downloaded Kobo Desktop onto my Linux machine, ran it through Wine from various different working directories, and it's always placed the "Kobo.sqlite" file into $HOME/.wine/drive_c/users/my_username/Local Settings/Application Data/Kobo/Kobo Desktop Edition/Kobo.sqlite.

Maybe the bug has been fixed with newer Kobo Desktop versions or with newer Wine versions?

[cyphar]

What version of Kobo are you using and how are you starting it? I have the 2021/10/30 (9bb7fadc79) edition installed (I tried to redownload the installer but even with a Windows user agent the download button isn't working).

There are warning messages in the log indicating that some environment variable is being set but some other code can't read it (and NICKEL_HOME is the path where you'd expect the data to be placed -- and the data is placed on your machine):

putenv "NICKEL_HOME=C:/users/cyphar/AppData/Local/Kobo/Kobo Desktop Edition"
NICKEL_HOME ISN'T SET!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
NICKEL_HOME ISN'T SET!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I'm launching Kobo using wine "~/.wine/drive_c/Program Files/Kobo/Kobo.exe" and am using Wine 7.4.

[noDRM]

I ran Kobo Desktop 4.24 which I found on some random website, as the download button isn't working for me either, with Wine 5.0. I'm going to see if I can find a newer Kobo and/or a newer Wine.

EDIT: Managed to download the most recent Kobo Desktop 4.30.16653 (30.10.21) through a Windows VM, same behaviour. Still writes to the correct folder, and I don't see these error messages anywhere.

Starting Kobo as usual, same way you are starting it.

Maybe it is a regression somewhere between Wine 5 and Wine 7.4, but if that's the case, then that should be fixed in Wine and not by adding an unperformant hack like this to the plugin, imo.

[natanb]

Here modify python source, that works under cygwin in command line:
$ python3 obok_br1.py
obok_br1.zip