335073 - Huge temporary working files XUL.mfl and XPC.mfl exhaust user disk space when user disk space restrictions are in effect

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Dan Yefimov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2) Gecko/20060419 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2) Gecko/20060419 Firefox/1.5.0.2

My users are under disk space restrictions which are generally sufficient for their casual work, but not in the case when they use either Firefox or Thunderbird or both, since huge cache files like XUL.mfl and XPC.mfl eat all disk space available to user. Those files presence in user profile is IMHO unfair, since they    
don't in fact carry any user preferences that are otherwise irreproducible. The practice shows that those files are regenerated every time Firefox or Thunderbird start, and no user preferences are lost if they are removed.

Reproducible: Always

Steps to Reproduce:
1. Log in as user with disk space restrictions on his home directory sufficient to hold Firefox or Thunderbird user profile while leaving some additional disk space (my users have 2MB disk space quota).
2. Create Firefox or Thunderbird user profile in the home directory.
3. After user profile creation start Firefox or Thunderbird (whatever appropriate).
Actual Results:  
XUL.mfl and XPC.mfl eat a bulk of disk space. If at some point no disk space is left while either program is running, the latter crashes (exception 0xC0000005, memory access violation).

Expected Results:  
Both Firefox and Thunderbird should create temporary working files like XUL.mfl and XPC.mfl either in temporary directory unconditionally (%TEMP% or %TMP% under Windows; /tmp under Unix), or have user preference setting pointing to the directory where those files must be created (like browser.cache.disk.parent_directory).

Comment 1

[Elmar Ludwig]

This may not solve your problem, but you can disable the XUL cache at least in Firefox by setting the pref "nglayout.debug.disable_xul_cache" to "true".

Comment 2

[Dan Yefimov]

Thanks for the info. But I'm sure I'm not the only person experiencing this problem. IMHO it should be documented somewhere or even that option should be added to the preferences notebook.

Comment 3

[Jo Hermans]

there were some ideas in bug 130041 that might help ...

Comment 4

[Dan Yefimov]

Unfortunately steps to work around this problem are undocumented. Firefox preferences notebook should have an option either to enable XUL fastload not switched on by default or to disable XUL fastload switched on by default, since the performance gain from XUL fastload is not that noticeable as one can expect while it introduces many problems pointed to by many people. In addition, Firefox or Thunderbird should not crash when disk space needed to hold XUL fastload cache is exhausted, otherwise speaking, neither XUL fastload cache content must be blindly trusted nor failure to store XUL cache in the fastload file should be the reason of program crash.

Comment 5

[Dan Yefimov]

The bug is observed also in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.2pre) Gecko/20070219 BonEcho/2.0.0.2pre

Comment 6

[Dan Yefimov]

While nglayout.debug.disable_xul_fastload does prevent XUL.mfl from being created, another big file, XPC.mfl is still created. Need a setting like nglayout.debug.disable_xpc_fastload to prevent XPC.mfl from being created.

Comment 7

[Nickolay_Ponomarev]

> since the performance gain from XUL fastload is not that noticeable as one can
> expect while it introduces many problems pointed to by many people.

Please don't make such claims without
a) pointing to a performance comparison of common actions with XUL cache enabled or disabled. In my experience, the performance boost is easily noticeable, and people wouldn't waste their time to work on a performance optimization that doesn't have any effect.
b) pointing to the "many problems pointed to by many people". I'm not aware of those.

If Gecko crashes when it runs out of space for the XUL/XPC cache, it's a bug and you should file one (unless it is already filed) and post the talkback id you get for the crash there.

The XUL/XPC cache is not stored in the profile folder as of Fx 2.0, don't remember when this change was made. It is stored in the "Local settings" area (Documents and Setting\<name>\Local Settings on NT), near the network cache. And the XUL/XPC cache is not "huge". The two files together are under 5 MB here. It must be a very specific situation if you can't give your users 25 MB of disk space for the temporary files.

Looking at the code I don't see a way to turn off XPC fastload.

Comment 8

[Dan Yefimov]

(In reply to comment #7)
> > since the performance gain from XUL fastload is not that noticeable as one can
> > expect while it introduces many problems pointed to by many people.
> 
> Please don't make such claims without
> a) pointing to a performance comparison of common actions with XUL cache
> enabled or disabled. In my experience, the performance boost is easily
> noticeable, and people wouldn't waste their time to work on a performance
> optimization that doesn't have any effect.

Your claims about the easily noticeable performance boost are proofless just like my claims stating the opposite. You in YOUR setup MAY experience the easily noticeable performance boost, while other people MAY NOT.

> b) pointing to the "many problems pointed to by many people". I'm not aware of
> those.
> 
If you're too lazy to search in the Bugzilla for XUL.mfl or XPC.mfl occurrences, that doesn't mean there're no such problems.

> The XUL/XPC cache is not stored in the profile folder as of Fx 2.0, don't
> remember when this change was made. It is stored in the "Local settings" area
> (Documents and Setting\<name>\Local Settings on NT), near the network cache.

Really? I do see both those files in the profile directory, rather than in the Local Settings directory (Firefox 2002pre 20070219, look at the comment #5).

> And the XUL/XPC cache is not "huge". The two files together are under 5 MB
> here. It must be a very specific situation if you can't give your users 25 MB
> of disk space for the temporary files.
> 
If you believe temporary files of 5 MB total size are not huge, it's your personal opinion. Don't expect other people sharing it. Yes, I DON'T wanna give my users more space for their home directories just for Firefox or Thunderbird to be happy with their temporary files. If some program needs creating temporary files, it must do that in the directory intended especially for such ones rather than in the directory intended for personal data.

Comment 9

[Nickolay_Ponomarev]

Not replying to most of your message since it was not relevant to the issue (and I was wrong to respond to those the first time).

> > The XUL/XPC cache is not stored in the profile folder as of Fx 2.0, don't
> > remember when this change was made. It is stored in the "Local settings" area
> > (Documents and Setting\<name>\Local Settings on NT), near the network cache.
> 
> Really? I do see both those files in the profile directory, rather than in the
> Local Settings directory (Firefox 2002pre 20070219, look at the comment #5).
> 
Really. While the old files probably do not get deleted from the profile folder, they are not used in 2.0.0.x.

> If you believe temporary files of 5 MB total size are not huge, it's your
> personal opinion. Don't expect other people sharing it.

I thought you filed a bug to get something changed in the software. Your opinion alone is not enough to get anything changed, since other people, as you noticed, may have a different opinion. You're expected to list the reasons this change is necessary, rather than posting a rant in the initial description, then flaming the person who tries to show you the initial report was just a rant.

> If some program needs creating
> temporary files, it must do that in the directory intended especially for such
> ones rather than in the directory intended for personal data.
> 
Which happens to be the "Local Settings" folder on Windows. And coincidentally, it's what modern versions of Firefox use.

Comment 10

[Dan Yefimov]

(In reply to comment #9)
> (and I was wrong to respond to those the first time).
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I completely agree.

> 
> > > The XUL/XPC cache is not stored in the profile folder as of Fx 2.0, don't
> > > remember when this change was made. It is stored in the "Local settings" area
> > > (Documents and Setting\<name>\Local Settings on NT), near the network cache.
> > 
> > Really? I do see both those files in the profile directory, rather than in the
> > Local Settings directory (Firefox 2002pre 20070219, look at the comment #5).
> > 
> Really. While the old files probably do not get deleted from the profile
> folder, they are not used in 2.0.0.x.
> 
Could you please explain in such case, why those files are still created in the profile directory even if I DO delete them, rather than in the directory you pointed out?

> > If you believe temporary files of 5 MB total size are not huge, it's your
> > personal opinion. Don't expect other people sharing it.
> 
> I thought you filed a bug to get something changed in the software. Your
> opinion alone is not enough to get anything changed, since other people, as you
> noticed, may have a different opinion. You're expected to list the reasons this
> change is necessary, rather than posting a rant in the initial description,
> then flaming the person who tries to show you the initial report was just a
> rant.
> 
Please read all my bug report, all previous comments to it, and all related bugs (which can be found by issuing a search in the Bugzilla for XUL.mfl and XPC.mfl occurrences) carefully before insulting me for "posting a rant". I pointed out all reasons I found, while your comments in fact look like a proofless rant.

> > If some program needs creating
> > temporary files, it must do that in the directory intended especially for such
> > ones rather than in the directory intended for personal data.
> > 
> Which happens to be the "Local Settings" folder on Windows.

Not necessarily. Conventional TEMP directory is that one pointed to by environment variables TEMP and TMP, which obviously may be different from that you point out.

PS. I believe Bugzilla is not the right place for off-topic disputes and personal flames. So please, if you don't have someting to say on the matter of this bug, don't say anything.

Comment 11

[Nickolay_Ponomarev]

> > Really. While the old files probably do not get deleted from the profile
> > folder, they are not used in 2.0.0.x.
> > 
> Could you please explain in such case, why those files are still created in the
> profile directory even if I DO delete them, rather than in the directory you
> pointed out?
> 
Problems with your setup I suppose. The correct path is:
Documents and Settings\<user name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\td4sryzb.default\

Comment 12

[Dan Yefimov]

(In reply to comment #11)
> > > Really. While the old files probably do not get deleted from the profile
> > > folder, they are not used in 2.0.0.x.
> > > 
> > Could you please explain in such case, why those files are still created in the
> > profile directory even if I DO delete them, rather than in the directory you
> > pointed out?
> > 
> Problems with your setup I suppose. The correct path is:
> Documents and Settings\<user name>\Local Settings\Application
> Data\Mozilla\Firefox\Profiles\td4sryzb.default\
> 
Yes, that is correct, but only if you create Firefox profile in the Windows user profile directory, which is the default. If Firefox profile resides somewhere else in order to either minimize the Windows user profile size to speed up logins or keep Firefox profile between sessions if the user is roaming, but either has no roaming profile assigned or has the mandatory profile assigned (which is my case), both XUL.mfl and XPC.mfl are created within the Forefox profile directory, which is undesirable for reasons I meant in the bug report.

Comment 13

[Wayne Mery (:wsmwk)]

shouldn't be an issue with FF 3?

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

If the profile is created in a different folder as the default one these files are still stored within the profile with Firefox 3.1. But beside these files you will also have problems with places.sqlite and urlclassifierx.sqlite. They are even big and need some space in the user profile folder.

Benjamin, any thoughts on that?

Comment 15

[Dan Yefimov]

places.sqlite contains bookmarks. Typical users have little of them, so it's size is quite small to care about. urlclassifierX.sqlite are created only if the corresponding function is turned on. If it is turned off, they are also small. BTW, if the directories named urlclassifierX.sqlite exist in the profile directory, FF runs fine without creating those files, but it would be nice if those files creation could be turned off with some user preference setting.

Comment 16

[Andrei Purice]

Hey Dan,
Can you still reproduce this issue or should we close it?

Comment 17

[Dan Yefimov]

(In reply to Andrei Purice from comment #16)

Hey Dan,
Can you still reproduce this issue or should we close it?

I don't use Firefox for 3 years yet, but as far as I remember, for FF 52 the files mentioned in the bug are not created in the user profile directory even if it's not in the Windows profile. Generally, it's 16 years passed since the original report, and everything has changed since that. Such old bugs are thus invalid yet.