lost of all stored passwords if out of disk space file truncated to zero length

RESOLVED WORKSFORME

Status

SeaMonkey
Passwords & Permissions
--
critical
RESOLVED WORKSFORME
14 years ago
6 years ago

People

(Reporter: vab, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {dataloss})

Trunk
x86
Linux
dataloss
Dependency tree / graph
Bug Flags:
blocking1.4.2 -
blocking1.6b -
blocking1.6 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029

If you are running the mozilla browser and run out of disk space, attempting
to save a new username/password pair to the password manager will result in
truncation and loss of all usernames and passwords currently stored.  

Reproducible: Always

Steps to Reproduce:
1.  fill your /home partition to 100% 0 bytes avail.
2.  tell mozilla to save a username/password web page form login
3.  exit mozilla
4.  go to a web site for which a username/password was stored (example: hotmail.com)
5.  notice that mozilla has forgotten your login information (ex: your hostmail
account name)

Actual Results:  
mozilla lost all usernames and passwords.

Expected Results:  
mozilla should have given a disk full error and not attempted to write the 
revised password database to disk.

This seems to be part of a group of problems associated with full disks across 
all platforms.  For example, mail messages to don't display when disk is full,
perfs are lost, cookies are lost, etc.  QA engineers should fill disk on all 
platfroms while running mozilla then restart and look for data loss bugs 
before 1.6b is released.
(Reporter)

Updated

14 years ago
Flags: blocking1.6b+
Flags: blocking1.6+
Flags: blocking1.4.2+

Comment 1

14 years ago
vab: if you want to nominate a bug to block a release, you should set the flag
to "?", not "+".
Flags: blocking1.6b+
Flags: blocking1.6+
Flags: blocking1.4.2+
(Reporter)

Updated

14 years ago
Flags: blocking1.6b?
Flags: blocking1.6?
Flags: blocking1.4.2?

Updated

14 years ago
Flags: blocking1.6b? → blocking1.6b-

Comment 2

14 years ago
see also bug 192425 bug 145558 and bug 145557

Updated

14 years ago
Status: UNCONFIRMED → NEW
Depends on: 228978
Ever confirmed: true
Flags: blocking1.6? → blocking1.6-

Updated

14 years ago
Flags: blocking1.4.2? → blocking1.4.2-

Updated

13 years ago
Blocks: 123929
Product: Browser → Seamonkey
Assignee: dveditz → nobody
Keywords: dataloss
No comments in over 4 years. Is anyone still seeing this bug on a recent SeaMonkey build?

(In reply to comment #2)
> see also bug 192425 bug 145558 and bug 145557
> 

Bug 145558 is "Windows", this one is "Linux". Are they different issues or should their Platform/OS be extended? The other two are FIXED by now.
QA Contact: privacy

Comment 4

8 years ago
No follow-ups from people continuing to say that this is still a problem on current Seamonkey builds on Linux. Resolving WFM. 

If you are still seeing this on current Seamonkey trunk builds on Linux, please post details and re-open this bug report.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.