apt-get purge doesn't delete data, and data location is not intuitive

Bug #1039079 reported by anthropornis on 2012-08-20
This bug affects 7 people
Affects Status Importance Assigned to Milestone

Bug Description

After running apt-get purge lightread, and then trying both logout and reboot, then re-installing LightRead, I am already logged in, as my Google account info was not deleted.

Moreover, manually deleting the data is a bit problematic if you don't already know where the databases are stored, and which databases pertain only to LightRead. The databases are stored in a non-intuitive location ( ~/.local/share/webkit/databases), and there are multiple databases, as well as a subdirectory containing another database, inside the webkit directory, making it difficult to determine which database(s) are relevant to LightRead.

Furthermore, it seems possible that other applications might also follow the same paradigm and rely on this shared webkit directory, making it even more difficult to determine which files/directories can be safely deleted without impacting other apps.

I had to install another program (sqliteman) to be able to inspect the databases, and doing this made it seem that nothing is cleared by apt-get purge and reboot, including feed and article data, in addition to the login data (which appears to be in ~/.local/share/webkit/databases/file__0/file__00000000000000001.db).

It would seem safer if any sqlite databases specific to LightRead are segregated in an explicit LightRead directory under either ~/.local/shared or ~./config (whichever directory is used by the majority of other apps, to make it more intuitive). More explicit file naming might useful too, but if all the files are at least in something like a ~./config/lightread/databases directory, then the file naming is less critical. Manually deleting that directory (if needed) would be less scary, even without installing sqliteman :)

Simonas (simonas-kazlauskas) wrote :

If I recall correctly, there's no way to tell webkit, where to store localstorage/IDBDatabase files.

Thomas Krüger (thkrueger) wrote :

This bug report is also related to an other problem:
If there is a situation in which Lightread has troubles reading or interpreting the user data and there for fails to start, there is no easy way to recover for a user who has no idea about the internals of webkit. I had a such a problem just some minutes ago in
https://answers.launchpad.net/ubuntu/+source/lightread/+question/206547 .

To allow the user to easily reset the application, I recomment to add a command line parameter "--reset", which will delete all user data and exit, before any data is used. On the next "normal" start the application will as on the first run again.
The actual loss of data would be minimal since mose content is pulled from Google. Only the authentication and a few settings would be lost.

anthropornis (anthropornis) wrote :

I'm starting to wish it wasn't tied to webkit.

Alex (aaaaalex) wrote :

This should be addressed asap as it renders the application useless once it strikes. There really should be an option to 'reset' or 'clear' all data.

Simonas (simonas-kazlauskas) wrote :

anthropornis, It will always be, however lightread has to be rewritten to use it's own cache in ~/.cache/lightread. To do that lightread has to get a nearly total rewrite from both functional and frontend side, which I'm trying to do at the moment.

Michael Wild (themiwi) wrote :

apt-get purge *never* deletes user data, so why should it do so with lightread? Ever uninstalled and reinstalled firefox, thunderbird, libreoffice etc.?

However, I do agree that using more XDG-conforming storage scheme would make things certainly easier.

consindo (cooperjona) wrote :

Currently we use the stupid WebSQL database. It has a location we can't change, has a max size of 5mb, causes bug #1031819 and when you logout, it deletes all the data from Nitro Tasks.

We'll be switching soon.

Changed in lightread:
status: New → In Progress
importance: Undecided → Critical
importance: Critical → High
consindo (cooperjona) wrote :

We rewrote it to store data with SQLite. It's not threaded yet so it's somewhat laggy but it works and stores it in a better place (~/.local/share/com.caffeinatedcode.lightread/db.sqlite3)

Changed in lightread:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions