327610 - Opening Firefox while disk is full erases profiles.ini

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: BackEnd, defect)

Description

[dolphinling]

Twice now when I've run out of disk space, my profiles.ini has been erased: not deleted, but turned into a 0 byte file. Obviously, this causes problems.

I'm not sure exactly how reproducible this is, and I haven't tried, but both times that I *know* I've run out of disk space, this has happened. Also of note is that both times the browser has crashed immediately before my noticing this.

Comment 1

[Philip Withnall (unavailable)]

I'd say this was a Linux thing, but the fact that Firefox doesn't like a 0-byte profiles.ini is acceptable, yet a dupe of your latter bug report. ;-)

*** This bug has been marked as a duplicate of 327611 ***

Comment 2

[Ben Fowler]

Although I haven't (yet) seen it, I would expect this to happen on Mac OS X as 
well.

What I would like to happen is that if writing out profiles.ini is unlikely to succeed (because disk free is < 10%), then it is left alone, even if out of date.
Maybe this is wrong ...

An alternative would be to evict pages from the cache (if the cache is on the 
same filesystem) whenever the browser wished to write to the disk and there 
was less than 10% disk free.

In the present case, where we are talking about one small but important file: on start-up, the browser could duplicate it to profiles.ini.$$, and when it came 
to  write out profiles.ini; write first to this one (which ought to succeed 
as it will not need to allocate more disk space), and copy over the old 
version (which ought to succeed as it will not need to allocate more disk 
space). When the browser finally exits, this scratch file can be deleted.

See:

Bug 187777 "new pages won't load if hard-disk is full"
Bug 216663 "startup fails with obscure error message when disk quota exceeded"
Bug 228978 "bandaid for disk full dataloss problems - warn user on start up 
that disk is nearly full and data may be lost"
Bug 236153 "firefox profile 'in use' if hdd is full"

Reports like this get Dup'd to Bug 228978, which is not being worked on!

Comment 3

[dolphinling]

Why do you say this is a dupe? This bug is "it can get erased", the other bug is "having it erased causes problems". 

Also, it happened again, and the pattern seems to be 
  Firefox is open
  Disk fills
  Firefox crashes
  Firefox is opened
  (short period of time and) Firefox crashes
  I check profiles.ini, and it's empty

So I assume that it's opening firefox while the disk is full that causes it to be erased.

Comment 4

[Philip Withnall (unavailable)]

(In reply to comment #3)
> So I assume that it's opening firefox while the disk is full that causes it to
> be erased.
> 

OK. Could you check the filesize of profiles.ini after every step in that list you just gave?

Comment 5

[dolphinling]

I tested this, and it is in fact opening firefox while the disk is full that erases it.

Comment 6

[Ben Fowler]

(In reply to comment #4)
> (In reply to comment #3)
> > So I assume that it's opening firefox while the disk is full that causes 
> > it to be erased.
> > 
> 
> OK. Could you check the filesize of profiles.ini after every step in that 
> list you just gave?

Philip, this is a True Bill. I can it happening in gdb. I have a patch for it that is nearly ready - you are very welcome to pip me to the post, mind.

Comment 7

[Wayne Mery (:wsmwk)]

Ben in comment #6:
> (In reply to comment #4)
> > OK. Could you check the filesize of profiles.ini after every step in that 
> > list you just gave?
> 
> Philip, this is a True Bill. I can it happening in gdb. I have a patch for it
> that is nearly ready - you are very welcome to pip me to the post, mind.

Ben, what patch or bug number would that be?

Comment 8

[Ben Fowler]

Sorry. I have not been able to build Firefox on Mac with anything approaching regularity, and I really wanted to be sure that I understood the code I was 
looking at before posting.

I do assure you that last time I checked, opening Firefox when the disk was full 
would truncate the file as stated in the original report. If memory serves, this appears to be happening in code that may not have been looked at since the 
Netscape days, and I suspect that any review/refactoring of this code by someone 
senior would lead to this bug being eliminated.

I will see if I can post what I have before Tuesday.

Comment 9

[Ben Fowler]

Attachment: Current work

(In reply to comment #7)
> Ben, what patch or bug number would that be?

Per request, I am uploading my current work on this bug. This patch is NOT of 
the quality needed for the Mozilla code base, let alone for a dataloss bug!

The meat of it is a bit hackish, but may be the correct fix.

It may also do more than required, which is a bit of a "no, no" for a bug fix 
intended to be rolled out.

The actual code and design here probably needs to be looked at either by its original author, or by someone senior and quite simply there may not be 
resources at our disposal to ensure this.

I hope that this stimulates someone to look into this bug, but I would also suggest that despite the dataloss tag this is not necessarily a high priority item as it is quite difficult to pull off and the defect has probably been in 
the code more or less forever.

For my future reference: Is there a canonical way of reporting an nsresult in
an NS_WARNING - something better than an 8 digit hex number, perhaps splitting
out the the elements that comprise the nsresult? Or should one provide a higher
level interpretation to the developer - it is to be hoped that end users never 
see NS_WARNINGS - and refrain from reporting the exact error?

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Unable to reproduce it with latest trunk, profiles.ini survives the full disk...

Comment 11

[Martin Stránský [:stransky] (ni? me)]

The propposed patch looks like the one I attached to Bug 237128...

Comment 12

[Benjamin Smedberg]

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.