User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729) Since Firefox 3.5 beta the cookie database file, cookies.sqlite, which is located in the profile directory is read locked during firefox's session. This affects thrid party cookie managers which need access to that file to read out or modify firefox's cookie data. Reproducible: Always Steps to Reproduce: 1. Open Fireforx 3.5 beta 2. Go to the profile directory and try to open the cookie file with an sqlite editor or similar. Actual Results: Either you won't be able to open the file or you won't be able to change it during firefox is running. Expected Results: The file can at least be read, or, as supported in Fiefox 3.0 even be changed during Firefox's session.
I would think that this is by design, at least a write lock. It's bad enough that external tools are killing our files with incorrect modifications but if Firefox is running they should not write to it.
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
The purpose of a database file may be to allow concurrent access. Firefox 3.0 aupported it well. Is there any change in 3.5 that accounts for this change? If read with a correct sqlite database engine, there is also no dager of incorrect modifications.
dwitte can come along and verify this, but this behavior is intentional. We open the database with an exclusive lock for performance reasons. See bug 449987 for details.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.