Open Bug 1493504 Opened 6 years ago Updated 2 years ago

out of space condition destroys browser files

Categories

(Firefox :: File Handling, defect, P5)

Product:
Firefox
Component:
File Handling
Version:
52 Branch
Type:
defect

Tracking

()

People

(Reporter: grgoffe, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170417065206 Steps to reproduce: I occasionally run out of space in my home directory where the .mozilla folder "lives". When this happens, writes to the folder fail. Sometimes without ANY notification! For example, this happens to the profiles.ini file which requires me to try to remember which profiles I have and which one I was using at the time of the error condition. I now have a backup of this file created for this precise situation. What other files are clobbered without notification? Actual results: see above Expected results: see above
Moving to File Handling component.
Component: Untriaged → File Handling
What we can do to mitigate this issue is to stop downloads if the free space in the partition falls below a certain threshold. If other programs fill up the available space, unfortunately the failure scenarios are so many that there is very little we can do to make the application robust. This is probably something that operating systems may theoretically support with quota management, but I don't know if there are APIs that can use to reserve space for in-use Firefox profiles.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Paolo, I have been running short of space in the same filesystem that .mozilla lives off and on in this system. I don't know why FF would be updating the profiles.ini file. I can see if you do any operations on profiles like add/delete/etc but otherwise, why would FF try to do this? I'm worried because I don't know what other files may be having this problem... unseen at this time but possibly lurking. If it were up to me, I'd add logic to make a backup file for each file to be updated/rewritten and then try to update/rewrite the file. If the rewrite fails, issue the appropriate warnings... save the backup file(s)... don't do "nothing". Perhaps computing the new file size and check the filesystem for at least enough free space to succeed with the update/rewrite... maybe twice the new size? I don't use quotas on this system but I "know" about quotas. I suspect that there's an api for queries though. Best regards, George...
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.