If no cookies file exists, it will never be created. On the other hand, if a cookies file already does exist (by copying it in from somewhere else), then the file will be updated properly each time new cookies are set. The problem started to occur with a change made last September (by Valeski). He changed the definition of NET_XP_FileOpen from XP_FileOpen to NET_I_XP_FileOpen in network/main/net_xp_file.h. Prior to that change, new cookie files were successfully being created.

Back to you Steve the Cookie Man!

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Fixed by making a change to network/module/nsNetFile.cpp

This works on windows, but I don't see this working on Macintosh at all. In fact, even if I copy a MagicCookie file over from my 4.5 profile, it doesn't read or write to it. Re-opening bug and modifying Summary.

If this is a mac-only bug, then there's not much I can do about it. Reassigning to a mac person.

Turning into a Mac bug and re-assigning to dp as, while I am a Mac guy, this is a job for the browser technologies group and not XPToolkit (which is where I sit in the brave new world)

Steve back to you. You should be driving fixing this. It would be wrong to throw other platform bugs in your module over the fence.

Welcome back Jud!

*** Bug 4900 has been marked as a duplicate of this bug. ***

Changing Target Milestone from M5 to M4 because this bug is a duplicate of 4900 which is an M4 bug.

Inserting comments from 4900: ------------------------------------------------------------------------------ www.netscape.com ... is getting hung reading my cookies file (on Linux), which looks very ugly for some reason. Every time you set a cookie, then exit, it appends the entire cookies file to the already existing cookies file, so you have a rapidly mutating file. Eventually, it must get too large. This could mess up Linux users.

Cookies being duplicated is being caused by NET_ReadCookies() being called twice. nsNetFactory::CreateInstance() was calling NS_InitINetService() and eventually via NS_NewINetService(), NS_InitINetService() was being called again. This resulted in two calls to NET_ReadCookies(), resulting in the in memory representation of cookies having two sets of the complete cookie file. Apparently this was a recent the result of a recent change to get rid of static initialization on Unix. I believe a fix can be applied by #ifdef'ing XP_WIN the section of code which calls NS_InitINetService() the first time in nsNetFactory::CreateInstance() Index: nsNetFactory.cpp =================================================================== RCS file: /cvsroot/mozilla/network/module/nsNetFactory.cpp,v retrieving revision 1.8 diff -c -r1.8 nsNetFactory.cpp *** nsNetFactory.cpp 1999/03/09 09:39:57 1.8 --- nsNetFactory.cpp 1999/04/13 05:13:54 *************** *** 126,137 **** --- 126,140 ---- *aResult = NULL; if (mClassID.Equals(kNetServiceCID)) { + + #if defined(XP_WIN) // No need create a new one if we've already got one. if (!gNetlibService) { res = NS_InitINetService(); if (res != NS_OK) return NS_ERROR_FAILURE; } + #endif /* XP_WIN */ // Hook the caller up. res = NS_NewINetService((nsINetService**)aResult, aOuter);

Turns the unix and mac problem were not the same bug after all (it was a mistake to consider this as a duplicate of 4900). The unix problem was not due to a bad file-open flag after all but rather to the cookie read-in occurring twice (see Hubie's analysis above). I have just made the change indicated by Hubie and checked in a new version of nsNetFactory.cpp. Not closing out the bug report yet because the mac problem still exists. But I am reassigning this bug back to myself so I can take ownership of it.

Changing Target Milestone to M5 since the remaining Mac problem is not as serious as the Unix problem was. And the unix problem is now fixed and has been checked into the M4 branch.

Steve, how are you writing to an empty cookie file? we may have had a similiar problem with the registry. If you just seek out to some arbitrary place in the file and start writing, MacOS will not make the file that big. you actually have to write real data from the end of the file to make the file any bigger. Does this sound familiar? Are you maybe skipping over a "header" and writing stuff in the middle of the file first?

No, I'm not doing any of the things you asked about. I am simply opening the file and writing to it. No seeking going on here.

Problem still exists in 4/26 build on Mac.

Unix problem has apparently not been fixed since several people are still reporting seeing cookies being duplicated resulting in very larg cookie files on unix. However, all the code that deals with cookies is going to be scratched and will need to be rewritten completely when necko comes along. So I'm closing this bug out as "won't fix". I'm sure the necko version will have introduce its own set of bugs.

Marking Verified/Won't Fix. Let' see how Necko does :-)

*** Bug 6401 has been marked as a duplicate of this bug. ***