Error peewee.OperationalError: database is locked on Flatpak profile

[hedgieinsocks]

Hi! I get peewee.OperationalError: database is locked error if I try to access the database when my Firefox Flatpak is running. I use the following to connect to the database fb.connect(look_under_path='/home/johndoe/.var/app/org.mozilla.firefox/.mozilla/firefox/johndoe.default-release'). I don't think it's related to Flatpak, perhaps I'm missing something?

[BURG3R5]

Sorry to hear that. This has never occurred during testing, so I need some additional info to find the exact issue.

1. Is it possible that you're using an extension/script that continuously monitors the bookmarks/places DB?

2. Does the following code work?

from firefox_bookmarks.connect import *

database = connect_to_places_db(criterion=ProfileCriterion.LARGEST)

[hedgieinsocks]

Thank you for your prompt reply!

I must provide the full path where the Flatpak version is installed, cause it looks only in the default path

firefox-bookmarks/firefox_bookmarks/locate.py

Line 64 in d17c384

return os.path.expanduser("~/.mozilla/firefox")

Unfortunately, with all the plugins disabled, the error persists.

But I've managed to interact with the database via cli by setting the immutable flag.

❯ sqlite3 'file:/home/USER/.var/app/org.mozilla.firefox/.mozilla/firefox/PROFILE.default-release/places.sqlite?immutable=1'

Perhaps it's possible to pass that flag here? If not, I'm already grateful for learning the search sql query from your examples.

[BURG3R5]

I think I can add a fallback to access the DB via file URI with the immutable flag. But just to confirm where the problem is, can you try the following code?

from firefox_bookmarks.connect import *

database = connect_to_places_db(look_under_path='/home/johndoe/.var/app/org.mozilla.firefox/.mozilla/firefox/johndoe.default-release')  # substituting your username, of course

I want to be sure that the issue is with the connect_to_places_db method, not with the _load or some other method.

[hedgieinsocks]

Yeah, with the suggested code it is the same. And I guess it is expected because vanilla cli sqlite3 results in the same database lock message at the first sql command. I can see that people workaround it by making a tmp copy of a database.

[BURG3R5]

Alright, I've reviewed the bug and decided on the following approach:

1. To ensure that users aren't surprised by their scripts silently using a temporary duplicate DB (that, at least for the time being, won't be synced with the original places.db), I'll have the connect method raise an Exception if the DB is locked.

2. The Exception's message will direct users to a different connect_read_only method, which will utilize a temporary duplicate.

[hedgieinsocks]

Sure, sounds nice. Since it works for you, but some people face my error, I guess it might be that some firefox packages are just compiled to use exclusive lock on db. Or maybe the underlying libraries play their role