Closed Bug 257288 Opened 20 years ago Closed 12 years ago

read-only profile files (cookies, bookmarks, etc) not respected, results in data loss

Categories

(Core :: Networking: Cookies, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: danm.moz, Unassigned)

References

Details

(Keywords: dataloss)

Attachments

(2 files)

Since bug 145557 taught Mozilla to try so very hard to save cookies that it can
actually (sort of) work around a file with read-only system permissions, the
once wonderfully convenient geek trick of keeping control over cookies using a
read-only file has become useless. In fact it's worse than useless. Mozilla is
still confused and unable to save cookies.

I know, I know. This trick is not supported. Phbbbbbt. It doesn't have to be
this way. Take a look inside an overinvasive file saving routine as it shuffles
your profile files around, trying to save cookies:
# -- begin attempt to save cookies
# new cookies saved to disk
$ ls -l cookies*
-rwx------    1 Grendel  None         1338 Aug 28 19:06 cookies-1.txt
-r--r--r--    1 Grendel  None         1142 Aug 13 15:26 cookies.txt

# original cookies moved aside
$ ls -l cookies*
-rwx------    1 Grendel  None         1338 Aug 28 19:07 cookies-1.txt
-r--r--r--    1 Grendel  None         1142 Aug 13 15:26 cookies.txt.moztmp

# new file renamed
# aww c'mon! the system gives you no privileges to mess with my cookies file!
$ ls -l cookies*
-rwx------    1 Grendel  None         1338 Aug 28 19:07 cookies.txt
-r--r--r--    1 Grendel  None         1142 Aug 13 15:26 cookies.txt.moztmp

# -- here's how the attempt to save cookies ends up:
# after attempt to delete the original cookies file
# ha! finally, you're stopped!
$ ls -l cookies*
-rwx------    1 Grendel  None         1338 Aug 28 19:07 cookies.txt
-r--r--r--    1 Grendel  None         1142 Aug 13 15:26 cookies.txt.moztmp

# -- after surfing for a few minutes
$ ls -l cookies*
-rwx------    1 Grendel  None         1338 Aug 28 19:16 cookies-1.txt
-rwx------    1 Grendel  None         1474 Aug 28 19:18 cookies-2.txt
-rwx------    1 Grendel  None         1543 Aug 28 19:18 cookies-3.txt
-rwx------    1 Grendel  None         2114 Aug 28 19:19 cookies-4.txt
-rwx------    1 Grendel  None         2114 Aug 28 19:19 cookies-5.txt
-rwx------    1 Grendel  None         1420 Aug 28 19:20 cookies-6.txt
-rwx------    1 Grendel  None         1420 Aug 28 19:21 cookies-7.txt
-rwx------    1 Grendel  None         1528 Aug 28 19:21 cookies-8.txt
-rwx------    1 Grendel  None         1528 Aug 28 19:22 cookies-9.txt
-rwx------    1 Grendel  None         1338 Aug 28 19:07 cookies.txt
-r--r--r--    1 Grendel  None         1142 Aug 13 15:26 cookies.txt.moztmp

As you can infer from the file sizes and date stamps, not only have my read-only
cookies been effectively modified, but they get stuck in an early modified
state. Let me punish that point a little harder:

*****************************************
Mozilla has effectively frozen my cookies at the point of its first attempt to
modify the file. I've effectively lost some data from my cookies *still* it's
unable to update my cookie information. Mozilla remains stymied by the read-only
file, and data loss continues.
*****************************************

At the very least, the SafeLocalFile code needs to be updated so that it's not
stymied by the read-only file it just pushed aside. A second option is to teach
it to respect my damn read-only files. Personally I prefer that option.
One possible solution would be to abort the process early if the file we're
attempting to save is completely unwriteable (has 0444 permissions). That would
save a *lot* of processing. But this patch seems more agreeable. It allows the
whole sequence to play out and then, right at the end, when it realizes it
won't be able to delete the *.moztmp file (thus starting the nasty sequence
that results in freezing the cookies file at an intermediate state), it
recants, renaming the moztmp file back to the original and throwing away the
new file.

What does everyone think? Personally I've been running with this patch on my
system ever since bug 145557 was fixed and have had no problems. To be fair I
must admit I've never had the profile dataloss problems some people complain of
constantly.
Attachment #157288 - Flags: review?(dougt)
The patch seem to be windows-only. Is the bug also windows only?

The other approach would be to create the temp file (cookies-1.txt) with the
same permissions as the original file (cookies.txt). Writing to that file would
fail, and the original file would not be touched.
It's Windows-only to *me*! But you're right, this wants to be ported to other
platforms. If we determine that this is a desirable thing to do (and this is the
right way to do it), I'll need some help with other platforms. At least among
the Big Three they're all very different.

I'm all for stopping the process earlier, but wouldn't creating the temporary
file with read-only permission leave behind undeletable temporary file(s)? In
the current Windows code the permissions of the original file are carried around
for a while but never really used. I suspect it's because it caused even more
trouble.
I know that on linux, deleting a file checks for permissions on the directory,
not on the file. So it won't be a problem there. (at least when deleting files
from the shell. didn't try the mozilla api's yet) It might be on windows though.
This bug occured in the branch between .9.2 and .9.3. It's persisted through PR1
and now RC1. I'm not sure if I've set the blocking status properly; I was trying
to follow Asa's instructions.

In my opinion, the "data loss" portion of the bug title is far less relevant
than the fact that Firefox does not respect the read-only file status and
proceeds to fill the profile directory with duplicate cookie files -- all of
which are read/write (so why more than one?).
Flags: blocking-aviary1.0+
Only driver@mozilla.org are allowed to set blocking-aviary1.0 +
Flags: blocking-aviary1.0+
Works for me using linux. is this windows only?

I am a bit surprised by the permissions on the files in comment 0.
nsSafeFileOutputStream tries to set the permissions for the new file the same as
the original. So it should not even be able to write into it.
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsFileStreams.cpp#525
(In reply to comment #6)
> Only driver@mozilla.org are allowed to set blocking-aviary1.0 +

Who or what is that? According to Asa...

If you do find regressions from the Preview Release, please file bugs in
Bugzilla and nominate them as Firefox 1.0 blockers using the
"blocking-aviary1.0?" flag on the bug.
--
http://weblogs.mozillazine.org/asa/archives/006789.html


That certainly sounds to me like I'm allowed. Perhaps you could explain.

Flags: blocking-aviary1.0?
(In reply to comment #8)
> That certainly sounds to me like I'm allowed. Perhaps you could explain.

you can set ? but you can't set +
Flags: blocking-aviary1.0? → blocking-aviary1.0-
great patch.  think we need platform parity.  Mike, any interest in unix; Simon,
any interest in Mac?
I would "prefer" that we not try to write at all if the file is read-only,
possibly with a once-only-able error message displayed to the user.  Permission
to write to a file is on many systems (I thought including NTFS) distinct from
the permission to modify the parent directory (such as by deleting the read-only
child).

But!

I'm not convinced that this is the right approach to this at all.  If we want to
suppress the alteration of cookies, let's add a pref that just stops cookie
writes, and people can about:config their way to victory.

In another bug (don't have it to hand) people complain loudly of pain brought on
by running their mozilla-spawn as root[*], resulting in a root-writable-only
bookmarks file in their profile.  With this patch, we would no longer be able to
recover "silently" from that case when running on that profile again as the
"real" user.  With a decent diagnostic, that could be less-than-completely
sucky, but my aforementioned reluctance to this whole approach remains intact. 
I think that in the 99% case the user really does want their data saved if
possible, and that we don't want to break that because 1% of users want to play
file permission games as a cheap way to keep saved cookies from changing between
runs.  There are other ways to do this, such as employing the init.d script
functionality or a wrapper script to write a known-good cookies.txt into the
profile before we really get going.

[*] Arguably -- indeed, I have thusly argued -- not what they want to do, but
the options for system-wide installation of an extension are sufficiently
limited and painful that it's a common case nonetheless.
(In reply to comment #11)
> I would "prefer" that we not try to write at all if the file is read-only,
> possibly with a once-only-able error message displayed to the user.  Permission
> to write to a file is on many systems (I thought including NTFS) distinct from
> the permission to modify the parent directory (such as by deleting the read-only
> child).

The "advantage" to write protecting the cookie file is that websites can sniff
the browser to see if cookies are enabled (or at least this was the case for
many years, and assumably still so) and as such, they can give web surfers grief
about not having cookies enabled. The usual result of that is that the sites
then block attempts to surf.

Because write protection occurs at the OS level, and not the application level,
 there's no way for sites to sniff the write status of the file because they
don't have access to the file system. What used to happen, is that new cookies
would just "bounce off" off the write protected file. What seems to happen now,
is that FF is doing more than a "blind" or "dumb" write. It seems to be getting
an error message and then compensating for it by generating a new cookie file.
And then generating yet another new cookie file for every cookie that tries to
write to the original file -- even though the new files generated are NOT write
protected.

I don't think that the code it would take to warn users of the write status of
their cookie file is all that necessary -- after all, FF is supposed to be
maximally streamlined. Unless the OS goes berserk, the only way for the file to
get write protected is for someone to do it manually, and if they're astute
enough to do that, then the warning would just be a nuisance. No one else would
ever see it.

It would be interesting to go back through the code tree and see if there are
any notes on why this behavior was changed. It used to be that FF handled the
write protection of the cookie file the same way Netscape did all those years
ago. The change came -- as I recall -- somewhere in the .9 series of releases.

Assumably, the behavior could simply be reverted.


> I'm not convinced that this is the right approach to this at all.  If we want to
> suppress the alteration of cookies, let's add a pref that just stops cookie
> writes, and people can about:config their way to victory.

There's already a preference to allow or deny cookies. The issue for me has
always been that write protecting the cookie file is a solution that does not
involve the browser. That's the attractive thing about it. I don't think that we
gain anything by adding more complexity to the browser. Do we?
There are certainly cases where the permissions on profile files are changed
unexpectedly; I outlined one above, as an example.

Changing the behaviour of a low-level file API to accomodate a rare cookie
maintenance use case is not high on my list of things to approve.  There are
other ways that work to achieve the same ends, and I would much rather see us
add a "no persistent profile data" capability, possibly with
cookie/bookmark/history/cert/all options, to address this and other related issues.

The complexity of checking a pref and skipping the save step is probably
equivalent to the complexity of putting these restore-if-RO-file pieces into
each of our different platforms' file impls, to say nothing of changing the
semantics in what I, at least, would find a very surprising way.  And it would
put the complexity where it should be, given how this bug is summarized: in the
cookie-maintenance code.
The corresponding bookmarks bug is bug 157152. With that bug as with this one,
in my opinion the problem is not how the file became read-only, but the terrible
things Mozilla does to itself when it stubs its toe on the read-only file. It
doesn't have to be so clumsy.

You hear about people with read-only files in their profile with some
regularity. Here's a recent one: http://sillydog.org/forum/viewtopic.php?t=8042
. No explanation; somehow the temporary file just became read-only. How many
other people have literally 10,000 bookmark files and just haven't realized it
yet? Do they notice the performance hit when Mozilla enumerates all those files
every single time it wants to flush their bookmarks to disk?

I stumbled into an interesting case myself recently. I set up a relative with
Firefox. Copied the program directory off a CD to her hard disk. I'm guessing
that the files used as templates to generate default profile files were
read-only, and that Mozilla isn't smart enough to fix that when it copies the
files. Profile full of read-only files, yay. Profile fills up with 10,000
identical examples of how to stub one's toe, yay.

Early abortion of the attempt to write to a read-only file would be more
efficient. I encourage you to drum up a patch. I had troubles with that
approach. The important thing is to get this silly bug fixed. It's the main
reason I never allow an official Mozilla build to touch my main profile.
danm, could you file a followup bug, assigned to me, about making profile files
read-write when we copy them from the defaults?
Blocks: 157152
imo the problem is that the new files (cookies-1.txt) doesn't get the right
permissions. see comment 0. If it would get the right permissions, trying to
write to the file would fail, and the new file would be deleted.
It seems that now writing succeeds, but moving it over the original fails, and
that error isn't returned. If it would, that could be detected, and the new file
could be deleted as well. Or maybe the error does get passed back. The code
doesn't try do delete in that case at the moment.

But i don't have a windows box to test. And it works for me on linux.
something like this patch. It doesn't fix the first problem, but it should
delete the temp file after failure of moving it over the target file. (should,
because i didn't test it. I don't use windows)
Comment on attachment 171204 [details] [diff] [review]
delete temp file after failures

r=me, if you want it.
Attachment #171204 - Flags: review+
Dan, are you gonna fix this, or review mvl's patch (or ideally do both ;-)?

/be
If I understand this right, all of these cookies-N.txt files are used and could
have desired data. Can this be cleaned up by CAT'ing them all to cookies.txt and
making sure it's RW (plus cookies.txt.moztmp)?
sorry for bugspam, but I want to make sure any patches that land is not
specifically for one or 2 files but ANY file FF tries to write to
this also happens to hostperm.1 and I suspect as well as to any user file in
your Profile that is readonly
Added my vote for this bug, with suggestion that if any file (bookmarks,
cookies, profile...) is R/O, Mozilla should simply
return and NOT create any new files. This will allow running Mozilla from R/O media.

pipr1
Assignee: danm.moz → nobody
*** Bug 310208 has been marked as a duplicate of this bug. ***
As a user (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6), I don't mind the application renaming a read-only
cookies.txt to cookies.txt.moztemp, and I don't mind it then creating a
read-write cookies.txt, but it seems to me that subsequently ignoring
cookies.txt and creating cookies-1, and then ignoring cookies-<n> and creating
cookies-<n+1> ad infinitum, must be a logical error.  Granted I'm not looking at
the code, but I don't see why it can't continue using cookies.txt as long as the
file is read-write, which it is (after it is created).  The application
apparently detects the read-only cookies.txt.moztmp at some point, or this
behavior would never be triggered.  It also apparently detects the cookies.txt
(or cookies-<n>.txt) it previously created, or it wouldn't proceed to create
cookies-<n+1>.  So it seems to me the knowledge is already there, it's just not
getting to the right place or being used in the right way.

I use a locked cookie file because there is no other way to override the Keep
Cookies preference for only specific cookies.  The ideal method would be if the
View Stored Cookies manager allowed individual cookies to be locked.  The
Exceptions manager is not approprate because it does not allow entry of
individual cookies (only entire sites) and does not provide Keep and Discard
properties (since Allow and Block do not apply to the Keep Cookies preference).
Comment on attachment 157288 [details] [diff] [review]
even SafeLocalFile can respect read-only files

clearing old request
Attachment #157288 - Flags: review?(dougt)
Can someone verify that the patch does cover all profile files?  This bug is ostensibly about cookies, but comment 15 suggests that the patch should cover other files as well.  If it does not, a separate bug needs to be filed for bookmarks and other files.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

Still a problem.  This appears to also cause bug #297313.  

One reason why a cookie.txt file might be read-only is to preserve some cookies as persistent while treating all others as session-only (even when they are served as persistent).  Even the latest cookie management options don't seem to support this.  
*** Bug 332569 has been marked as a duplicate of this bug. ***
Summary: read-only cookies file not respected, results in data loss → read-only profile files (cookies, bookmarks, etc) not respected, results in data loss
I vote for this bug.
I'm using latest version (1.5.0.3) and in this month firefox was very slowly, and it get ever worse.
Indeed, I was thinking to back to Internet Explorer! A crime!
I come across the profile folders, and i found 999 cookies-N.txt files! When i delete them (through firefox, windows crash with so much files) firefox seems like refive. I make an entirely scan of hard disk, 'cause i think was a worm or a trojan. I clean it, but today i found that firefox keep creating these files. In few hours i found 100 files. And firefox start again to be so slow!
I hope this bug will be soon fixed.
This is a problem for ordinary vanilla Firefox users (on Windows XP) like me.  See my long report in the Mozilla Firefox Support Forum ( http://forums.mozillazine.org/viewtopic.php?p=2528685#2528685 ).  I did not at any time purposely make the cookies.txt file read only - in fact I did not even know what folder it would have been in until yesterday.  I have been running Firefox 1.5.0.7 on a Dell Notebook:

Processor Intel(R) Pentium(R) M processor 1400MHz
Processor Speed 1.37 GHz
Memory (RAM) 1024 MB
Operating System Microsoft Windows XP Professional
Operating System Version 5.1.2600

The problem is that in early September I started having Firefox hang using 100% of the CPU for about 8 seconds every 15 to 30 seconds or so.  I got no help from the Forum and reposted my problem yesterday.  It was suggested I try Firefox 2.0 RC2 but, unfortunately Firefox 2.0 RC2 still had the problem.  What fixed my problem was to create a new profile.  As I was trying to copy SELECTED files from my old default profile to the new one, I discovered that I had 2236 files of the form cookies-NNNN.txt.  Now, as I say I never tried to make anything read only.  Looking at the dates of the files I find the following for the first (and last) few:

02/13/2006  01:57 PM            69,893 cookies-1.txt
04/18/2006  02:56 AM            77,817 cookies-2.txt
04/18/2006  04:56 AM            77,774 cookies-3.txt
05/14/2006  08:30 PM            15,968 cookies-4.txt
07/08/2006  07:40 PM            58,968 cookies-5.txt
07/30/2006  06:25 PM            75,811 cookies-6.txt
08/06/2006  08:06 AM            19,111 cookies-7.txt
09/03/2006  04:21 PM               275 cookies-8.txt
09/03/2006  04:22 PM               334 cookies-9.txt
09/03/2006  04:24 PM               334 cookies-10.txt
....2200+ lines deleted.....
09/05/2006  06:23 PM             1,009 cookies-2234.txt
09/05/2006  06:23 PM             1,009 cookies-2235.txt
09/05/2006  06:23 PM             1,009 cookies-2236.txt
10/07/2006  07:56 PM             1,563 cookies.txt (<<this is small because I tried to clear all cookies from the UI, but it did NOT clear all the 2000+ cookies files - yesterday this was about 30K before I cleared all cookies>>)

So, I was getting about a copy per month or so created between February and September.  On September 3, disaster struck and I started to get a copy created every few minutes until September 5 for a total of 2229 additional copies beyond the 7 over the previous 7 months.  I am not sure what exactly caused this disaster in September, but I suspect it was the extension Gmail Manager 0.5.1 (August 28, 2006) which I had downloaded at about that time.  I had experimented with a number of new extensions at that time so I am not absolutely sure it was Gmail Manager, but I could never get the Gmail Manager to work so I eventually uninstalled it.  That could have been when the cookie duplication stopped on Sept 5.

So, there are two problems:  

A. Why did 7 copies of the cookie file get created over 7 months?
b. Why did 2000+ copies of the cookie file get created in 2 days?

I think you really do need to change the code so this (A or B) does not happen again.  As I said, I never purposely made the cookies.txt file read only.  Some suggested that Panda software could cause this kind of problem but I do not have that software.  I am running Mirra software to backup files to an external box continuously in the background, but I had not pointed the Mirra software to this profile directory so I don't think that could have caused the problem. Problem B is the more severe problem that may have been caused by some interaction with an extension so maybe you will ignore that. But problem A is still a problem that I think should be fixed in the Firefox code itself.  PLEASE?!
 

So perhaps the 7 copies in 7 months were do to transient file system errors?  I don't know, but I think it is unreasonable for Firefox to create even 7 copies of the cookies file, and definitely it is unreasonable to create 2000+ copies.  With the 2000+ copies, Firefox+Gmail was unusable for me for more than a month (and I did not know why).  So for the past month I was FORCED to have Firefox open for all my other web browsing and Internet Explorer (BOO HISS) open to read my mail from GMail.  I suspect the tremendous slowdown for GMail was because these 2000+ small files all seemed to mention my gmail email address.

For example the "URL" text strings in cookie-100.txt are: gmailchat fbh1949@gmail.com google.com google.com mail.google.com findory.com www.google.com aus2.mozilla.org yahoo.com www.theledger.com www.google.com.

Please fix this problem!  I cannot verify that Firefox2.0 RC2 will create all these files, but it is definitely a problem for RC2 if the files already exist! 

(In reply to comment #30)

PS: There is no file named cookies.txt.moztmp in the directory at all and again none of the cookies-NNNN.txt files were read-only or hidden and the file cookies.txt was also not read-only or hidden.  So the "read-only or hidden" issue is not causing the 7 or 2000+ cookies file duplications I have experienced.
HELP!!!!

The problem is still happening!  I noticed 100% CPU with Firefox occasionally today and went and looked at my cookies list and found 133 cookie files.   It looks like I get almost 10 copies of the cookie file each day and that it started just when I made just before my last posting on Oct 9, 2006 and continued up to today.   Some of these copies are created in the middle of the night when I am not at my computer.  I usually leave Firefox running 24/7.  I have NEVER made the cookie file read-only or played any other games with the cookie file and there is no moztmp file.  Each file is getting bigger and bigger each day.  So the cookie file duplication bug is still happening.  All this time I ran in a new profile with Firefox 2.0 RC 2.  I will clean out the copies of the cookie file and download and install the official Firefox 2.0 release today and see how things go from here.  I hope someone will work on and fix the cookie duplication bug soon.  I think I am a fairly sophisticated user (20+ years of SW development employment) and it took me a long time to discover the duplicated cookie files as being the cause of my 100% CPU problem.  There must be MANY novice users out there experiencing this problem who have no idea of the cause.  I hope some future version of Firefox will not only STOP duplicating cookie files, but will also clean up all the duplicated cookie files automatically.

Here are the first few and last few directory entries from a dir /od cook*.txt command:

10/08/2006  05:38 PM             8,045 cookies-1.txt
10/08/2006  09:06 PM             7,883 cookies-2.txt
10/09/2006  01:52 AM             8,555 cookies-3.txt
10/09/2006  10:15 AM             8,471 cookies-4.txt
10/09/2006  05:47 PM            10,268 cookies-5.txt
10/09/2006  07:46 PM            11,770 cookies-6.txt
10/09/2006  07:52 PM            11,840 cookies-7.txt
10/09/2006  09:50 PM            11,775 cookies-8.txt
10/09/2006  11:42 PM            11,713 cookies-9.txt
10/09/2006  11:59 PM            11,775 cookies-10.txt
10/10/2006  02:45 AM            11,735 cookies-11.txt
10/10/2006  03:26 AM            11,713 cookies-12.txt
10/10/2006  04:22 AM            11,775 cookies-13.txt
10/10/2006  06:42 AM            11,713 cookies-14.txt
.........
11/14/2006  02:04 AM            38,303 cookies-121.txt
11/14/2006  03:02 AM            38,241 cookies-122.txt
11/14/2006  01:34 PM            38,656 cookies-123.txt
11/15/2006  02:14 AM            38,776 cookies-124.txt
11/15/2006  06:51 AM            38,838 cookies-125.txt
11/15/2006  07:10 AM            38,687 cookies-126.txt
11/15/2006  07:23 AM            38,687 cookies-127.txt
11/15/2006  08:11 AM            38,687 cookies-128.txt
11/15/2006  09:01 AM            38,516 cookies-129.txt
11/15/2006  01:18 PM            38,454 cookies-130.txt
11/16/2006  01:19 AM            38,516 cookies-131.txt
11/16/2006  01:35 AM            38,516 cookies-132.txt
11/16/2006  03:47 PM            39,829 cookies.txt
             133 File(s)      3,182,639 bytes
This may be unrelated, but I also found 11 versions of sessionstore*.js that were created over the same time frame of Oct 9 to Nov 16, At least these are only 11 instead of 133 but I bet it is a similar situation somehow.  HELP!  Here is the dir results:

10/08/2006  04:57 PM            44,082 sessionstore-1.js
10/09/2006  08:16 PM            49,864 sessionstore-2.js
10/15/2006  01:57 PM            37,588 sessionstore-3.js
10/16/2006  06:43 AM            35,448 sessionstore-4.js
10/25/2006  03:26 PM            28,711 sessionstore-5.js
10/25/2006  09:30 PM            30,841 sessionstore-6.js
11/02/2006  09:12 PM           129,878 sessionstore-7.js
11/03/2006  09:56 AM            34,412 sessionstore-8.js
11/08/2006  07:10 AM            20,675 sessionstore-9.js
11/14/2006  10:45 AM            41,086 sessionstore-10.js
11/16/2006  04:07 PM             2,721 sessionstore.js
              11 File(s)        455,306 bytes

I have now installed Firefox 2.0 and deleted the extra cookies-N.txt and sessionstore-N.js files.  I will keep you posted if I start getting more of these files...
This is NOT the same as bug 375778.  This bug reports that, when a file is read-only, the Cookie Manager writes a new file with the old file's name and a numeric suffix.  However, in this bug, the properties of the read-write file were not changed.

Bug 375778 reports a change in the properties of read-only files, to read-write.  This is something new within recent Gecko or UI versions and was not happening as recently as 11 November 2006 (the time of comment #33 in this bug).  

Note that bug 375778 hides the effect of bug 257288 by changing read-only files to read-write.  Since read-only files are not found, the erroneous behavior reported in bug 257288 does not occur.  This must NOT be considered a fix for bug 257288 since bug 375778 makes things worse instead of better.  

Also note that, if no software changes were made and bug 375778 was left as a duplicate of bug 257288, then bug 257288 could be closed.  After all, the error reported in bug 375778 now eliminates the symptoms described in bug 257288 (as explained in the paragraph above).   

 
As of Firefox/2.0.0.2 this bug of duplicating files still exists.  Over the past month and a half with this version, I have had 66 copies of cookies-NN.txt files and 21 copies of sessionstore-NN.js files created in my profile directory.

I NEVER make the cookies.txt or sessionstore.js files read only.  I suspect that something on my system (maybe my Mirra backup software) occasionally competes with Firefox for access to these files which causes all these duplicates to be created. If someone thinks this is correct behavior, OK, but then, when the files can be correctly read and written shouldn't the duplicates all be merged into on cookies.txt file with all extra the cookies-NN.txt files being cleaned up and deleted?   In other words, whenever the cookies.txt file is correctly written to disk, check for the existence of cookies-NN.txt files and delete them since the correct cookies data has now been saved.  Does this make sense?

In any event, please fix this bug, somehow, somebody!
Confirmed on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 .  I use a locked cookie file.  When I switched from Windows 2000 to Windows XP, the problem stopped being apparent because somehow on XP, Firefox was able to completely disregard the read-only file attribute....  Now on my 1-month-old MacBook I just discovered 2,488 cookie files.  Happy happy joy joy.
The disregarding of read-only is bug #375778.  
Is bug 109377 related to this one? Are they the same issue? And if they are, which one should be duped to the other? This one (which has more data) or the older one (which is older)?

Oh, and BTW: this cannot be for "Networking:File" which would be about the "file:///" protocol. Moving to Networking:Cookies. Benc@meer, this will clear your "assigned" status -- ACCEPT again if you want it back.
Component: Networking: File → Networking: Cookies
QA Contact: benc → networking.cookies
(In reply to comment #42)
> *** Bug 109377 has been marked as a duplicate of this bug. ***
> 

reopened, see bug 109377 comment #8
Keywords: dataloss
Bug 109377 seems to refer to FF not communicating file permissions to the user (causing data loss), not FF disrespecting file permissions (causing data loss).

This bug seems to refer to FF disrespecting file permissions, which 3.0.x still does.  I tried making cookies.sqlite read-only; FF3 reacted by not using the contents at all.  I.e., it disrespected the "read" part of "read-only".

The only way I've found to retain only user-specified cookies between sessions is to completely replace cookies.sqlite between sessions, and the only free way I've found to maintain my own cookies.sqlite is with downloaded sqlite3.  I still don't understand why the FF cookie manager allows viewing and deleting individual cookies but not locking, editing, and creating them.  Then I would have no need to lock the entire file.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7
Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20111221 SeaMonkey/2.6.1

It appears that this bug is now fixed, at least with respect to cookies.sqlite.  Actually it seems to have been fixed not later than (and perhaps prior to) the release of SeaMonkey 2.5.
Blocks: 109377
> It appears that this bug is now fixed
I'm going to close this for the time being. Please re-open if you still see issues.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.