Last Comment Bug 455075 - cookies.sqlite-journal constant write/delete causes constant AV scanning & Norton Protected Bin buildup
: cookies.sqlite-journal constant write/delete causes constant AV scanning & No...
Status: VERIFIED WONTFIX
:
Product: Toolkit
Classification: Components
Component: Storage (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Marco Bonardo [::mak]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-12 14:04 PDT by Terry R.
Modified: 2009-06-23 13:49 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Terry R. 2008-09-12 14:04:53 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

I use Norton Protected Recycle Bin (only, not the AV portion).  On a daily basis I now have thousands of the file cookies.sqlite-journal being stored.  This is causing a reduction in available disk space and the Protected Bin is having to be cleared frequently.  Another result of the constant creation of the file cookies.sqlite-journal is constant scanning of the Anti Virus program.  I'm sure any workstation using Shadow Copy will also experience unneeded storage of these files.

I used Process Monitor to view this constant creation/deletion of this file and the AV scanning.  This places an unnecessary hit on disk activity and processes.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox
2. Open Process Monitor (Sysinternals) and search for cookies.sqlite-journal (must include the full path with the filename).  Press F3 to move to each process taking place on the file.
3. If a user uses Norton Protection Recycle Bin, open it and search for cookies.sqlite-journal.  There will be over 1,000 files stored PER DAY (I had 1,460 yesterday).
Actual Results:  
I realized this is not a feature I want.  Either it gets "fixed" or I start removing Firefox from all my client machines.  Many are networks that use Shadow Copy at the server level and this is not good design.

Expected Results:  
Not to have constant disk and AV activity caused by running my browser!
Comment 1 Matthias Versen [:Matti] 2008-09-12 15:28:40 PDT
We had many corrupt files in the past because of OS crash, system Power down etc during the writing of files.
We now use a SQlite database with a journal and the journal avoids corrupt database files.
A shadow copy only keeps a very limited set of old files around, that should not be a problems at all.

I can not see a reason to disable the journal for the database and that is no bad design at all. If a webpage requests to read/write cookies then the cookie files must be changed on the disk.
Comment 2 Shawn Wilsher :sdwilsh 2008-09-12 15:35:13 PDT
This is part of the behavior of a database.  This is intended, and there's no way to get around it.
Comment 3 Terry R. 2008-09-13 08:12:55 PDT
If the OS is crashing or files are getting corrupt from a simple power down, there are other issues that need to be resolved.

It is poor design to have the "cookies" database be written thousands of times a day, causing constant disk writing and AV scanning and unnecessary files being copied (shadowing or protected files).  They're cookies, not valuable data!

At the very least it should be a user option to disable or change the frequency of writes.  It shouldn't be imposed on the user in this way.

Changing the cookies on a site by site basis and having a database write thousands of times a day to disk are two completely different things.  And a waste of resources.

Because of this, I will now be uninstalling FF on all network workstations that I admin.  The users don't need the performance hit and the servers don't need to be shadowing every users cookies journal thousands of times a day.  


(In reply to comment #1)
> We had many corrupt files in the past because of OS crash, system Power down
> etc during the writing of files.
> We now use a SQlite database with a journal and the journal avoids corrupt
> database files.
> A shadow copy only keeps a very limited set of old files around, that should
> not be a problems at all.
> 
> I can not see a reason to disable the journal for the database and that is no
> bad design at all. If a webpage requests to read/write cookies then the cookie
> files must be changed on the disk.
Comment 4 Terry R. 2008-09-13 08:19:57 PDT
Intended or not, it needs to be changed.  We're not talking about valuable data, we're talking about cookies.  What could be so important that it needs to be written to thousands of times a day?  Most of the time I don't even accept cookies, so I could care less if they are being journaled or not.  Create a user pref that allows disabling. Better yet, it should be disabled on installation with an option to enable.  I don't believe any user cares about this like the devs do.

I'm not going to go around to all the workstations I admin and set exclude rules for AV and Shadowing.  If the clients found out I was doing this (especially since I was the proponent for FF in the first place), it would not bode well for me.  I will already have to eat my time removing FF from user workstations.

(In reply to comment #2)
> This is part of the behavior of a database.  This is intended, and there's no
> way to get around it.
Comment 5 Matthias Versen [:Matti] 2008-09-13 08:39:59 PDT
That the AV software is scanning a file that only contains data and never a virus isn't our fault at all. The shadow database only keeps a very limited history and that should not be a problem. There is no OS API to modify the file without been copied to the shadow database and that means there is nothing we can do. Every browser writes the cookie file all the time which should result in a copy to the shadow database, we additional have the journal file.

If you don't need cookies doesn't mean that other people don't need them.
We had people complaining that we don't import the IE cookies for example.

There is a way to disable the writing, disable cookies in Firefox and it should not write to that file.

I agree here with the Module owner of Storage and mark this verified invalid
Comment 6 dwitte@gmail.com 2008-09-13 14:09:13 PDT
(In reply to comment #5)
> There is a way to disable the writing, disable cookies in Firefox and it should
> not write to that file.

alternatively, just set "keep until: end of session" in the cookie pref panel.
Comment 7 Terry R. 2008-09-14 10:25:05 PDT
(In reply to comment #5)
> That the AV software is scanning a file that only contains data and never a
> virus isn't our fault at all. The shadow database only keeps a very limited
> history and that should not be a problem. There is no OS API to modify the file
> without been copied to the shadow database and that means there is nothing we
> can do. Every browser writes the cookie file all the time which should result
> in a copy to the shadow database, we additional have the journal file.
> 
> If you don't need cookies doesn't mean that other people don't need them.
> We had people complaining that we don't import the IE cookies for example.
> 
> There is a way to disable the writing, disable cookies in Firefox and it should
> not write to that file.
> 
> I agree here with the Module owner of Storage and mark this verified invalid

ANY AV software that does real time scanning will have this behavior.  The AV software doesn't know until the file is scanned that it's virus free, does it!

What is "limited" in your mind regarding shadowing?  I had over 1,200 files in ONE day!

I did NOT say I don't use cookies.  It is ludicrous to believe that any user needs this kind of constant journaling for cookies.  Disabling cookies in a browser today makes the browser virtually useless on most sites, so that is NOT any kind of resolution.

I will do what I can to get word out on this behavior in FF.  Maybe if it gets a larger public attention, someone will see their design needs to be fixed.
Comment 8 Terry R. 2008-09-14 10:26:23 PDT
(In reply to comment #6)
> (In reply to comment #5)
> > There is a way to disable the writing, disable cookies in Firefox and it should
> > not write to that file.
> 
> alternatively, just set "keep until: end of session" in the cookie pref panel.

I doubt that will prevent any journaling from happening as it is constant while FF is open.  And disabling cookies isn't a resolution either as everyone is well aware of.
Comment 9 dwitte@gmail.com 2008-09-14 12:13:57 PDT
(In reply to comment #8)
> I doubt that will prevent any journaling from happening as it is constant while
> FF is open.  And disabling cookies isn't a resolution either as everyone is
> well aware of.

it will. it's also not disabling cookies, it's making them nonpersistent.
Comment 10 maltby 2008-09-23 10:53:13 PDT
For a much simpler case:

I found this thread via tracking down what was constantly thrashing the drive on one of my HomeNet machines.  I just dislike needless disk thrashing in general (call me old fashioned)...   My first thought when I see it is: "Bad Design" or, if you prefer, "Design Opportunity".     

With a little further exploration I now see that the "thrashing" is only chronic on dynamic web pages (flash, etc) where quite probably cookie activity is being regularly requested.  FF's behavior then seems reasonable, and in MY CASE, acceptable.  I can just use cookie exceptions if I'm that uptight.  

As a retired IT guy, I think Terry R.'s dilemma is well founded and well stated.  I would can the Norton trash can widget, but he cant be alone on the shadowing and other issues.  All I hear is "not our fault, just cant fix it, invalid complaint, thats the way databases are....".   No, gentlemen, thats the way YOUR database is.   Perhaps you need a "less.robust=true" switch for the damn cookies.  He's not going to remove browsing from his net, just your browser, and THAT would be a pity.      

OK, OK, you dont have a problem! You may have an opportunity....

PS Heartfelt thanks for Firefox.

--MRM
Comment 11 Mark Trompell 2008-11-14 00:03:10 PST
In our environment, we have all our User Profiles on a Mapped drive on one Fileserver. After switching to firefox3 access to the server slowed down, significantly, so that the server was almost unusable. Some investigation, lead me to this bug.
We think that ~100 peoples firefoxes permanently writing files on the fileserver, is the cause of that slowdown and makes ff3 unusable in ebvironments like ours. For now we switched back to ff2, which doesn't seem to have that problem.
This shouldn't be a won't fix bug.
Comment 12 Matthias Versen [:Matti] 2008-11-14 00:57:41 PST
I bet you got hit by fsync and this should be much better with FF3.1beta builds.
Thew writes for the journal are are small and shouldn't hit your file server.
Comment 13 Jeff Morriss 2009-04-07 07:59:18 PDT
(In reply to comment #12)
> I bet you got hit by fsync and this should be much better with FF3.1beta
> builds.
> Thew writes for the journal are are small and shouldn't hit your file server.

I found this bug after noticing a lot of disk thrashing while FF was open.  As someone else mentioned (here or on a mailing list somewhere), simply closing the tab with my iGoogle home page made the disk thrashing go away.

More importantly, installing FF3.1 Beta 3 also made the problem go away.  :-)
Comment 14 Jeff Morriss 2009-06-23 13:49:05 PDT
(In reply to comment #13)
> (In reply to comment #12)
> > I bet you got hit by fsync and this should be much better with FF3.1beta
> > builds.
> > Thew writes for the journal are are small and shouldn't hit your file server.
> 
> I found this bug after noticing a lot of disk thrashing while FF was open.  As
> someone else mentioned (here or on a mailing list somewhere), simply closing
> the tab with my iGoogle home page made the disk thrashing go away.
> 
> More importantly, installing FF3.1 Beta 3 also made the problem go away.  :-)

Hmmm, but when my Beta upgraded itself to 3.5, the problem is now back.  :-(

Note You need to log in before you can comment on or make changes to this bug.