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.
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?).
Only firstname.lastname@example.org are allowed to set 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 email@example.com 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.
(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 +
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?
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
*** 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
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:184.108.40.206) 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 (220.127.116.11) 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 18.104.22.168 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 firstname.lastname@example.org 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/22.214.171.124 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:126.96.36.199) Gecko/20070309 Firefox/188.8.131.52 . 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
Duplicate of this bug: 109377
(In reply to comment #42) > *** Bug 109377 has been marked as a duplicate of this bug. *** > reopened, see bug 109377 comment #8
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:184.108.40.206) 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.
> 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
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.