499099 - cookie database file in profile folder is read locked with firefox 3.5

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, defect)

Description

[jm]

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.

Comment 1

[Matthias Versen [:Matti]]

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.

Comment 2

[jm]

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.

Comment 3

[Shawn Wilsher :sdwilsh]

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.