User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

When some other process fills user's home file system to 100% - and Firefox is running, there is likely VERY HIGH probability user will loose its logins & passwords stored in this file.

Actual results:

logins.json was gone and only the file with 'corrupted' suffix and size 0 was left
and there was NO last valid backup present.
So after restart of Firefox I was asked to enter passwords for google.com....

Thankfully I had some backup.
And no I do not want to store my passwords in any Mozilla or anyone else cloud.

Expected results:

Firefox should NEVER ever try to unsafely updates files like this want.
I don't really care much about i.e. visited link history. I could probably even live with lost cookies - but loosing logins is quite serious problem.

So before the original file is replaced - it should have been first written as 'new'.
Only when new file is 'synced' on filesystem - then it's likely OK to remove the old one.

The other question is - WHY this file actually needed to be updated in the moment my home dir when out of space - it does look the file hold relatively long-term persistent data as 'name&password' together with its last use time stamp.
Again risk variant where timestamps should probably be part of a different 'more frequently update' databaze, while password could be there only occasionally updated.

Sorry this happened to you. Can you provide more details regarding what happened? What caused the file system to reach capacity (was it something in Firefox or another application)?

We did recently land a mitigation for unexpected corruption of logins.json (Bug 1593467) that landed in Firefox 80, so it should be creating backups in any later versions. Can you check what version of Firefox you are running? You can get this and much more information by navigating to about:support in the URL bar.

The reason of filesystem overfill was in this case unrelated to Firefox - application running in parallel consumed unexpected huge amount of disk space filling all the available free block at /home block device (with .mozilla dir inside).

This bug already has happened to me in past with older version (and in that case I've had much older backup) - so this is definitely not a new issue
but my current version is: Firefox 81.0.1 20200930210256 Fedora Linux (I'm rawhide user of Fedora).

Reproducer should be simple - place .mozilla/firefox dir into a filesystem that runs out of space and continue using Firefox for a while until 'corrupted' logins.json appears.

Thanks for the report. It is curious that there is no logins-backup.json in your profile. Next steps would be to reproduce this and see under what circumstances the backup is not created and if there's anything practical we can do in that scenario.

There actually was one - but useless - it has missed i.e. all my google accounts - so it's not been clear to me how old or useful this file was and I'd already removed the file. Maybe the file has been not properly fully written while the space got missing - i.e. when there is missing call to 'fsync()' before calling fclose() on a filedescriptor - so the close will appear as successful while the pending page cache writes will fail later.

I'm mostly pretty sure I could reproduce the issue again - so I could collect more info - if you ask what do you exactly want to see.
(since before making the report I'd retried and hit the issue again).

Note - I do expect there might be some problems - even FF might happily crash in this case when the FS gets out-of-space.
It's way better then silently losing my logins and continue to work as if nothing had happened - as when the temporary out-of-disk-space
condition goes away and files are removed - the logins.json destruction was permanent and completely hidden (but since I'd not too old backup, not to big problem since the lesson has been learned last time already....)