cookperm.txt / hostperm.1 truncated when disk full

RESOLVED FIXED in mozilla1.8alpha1

Status

()

Core
Networking: Cookies
P4
critical
RESOLVED FIXED
16 years ago
12 years ago

People

(Reporter: Ben Goodger (use ben at mozilla dot org for email), Assigned: Michiel van Leeuwen (email: mvl+moz@))

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {dataloss, fixed-aviary1.0})

Trunk
mozilla1.8alpha1
x86
Windows 2000
dataloss, fixed-aviary1.0
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.6 -
blocking-aviary1.0 +
blocking1.8a2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

This bug is split of 86501. The reporter in that bug cites the file
'cookieperm.txt' being truncated when shutting down after the disk is full. Not
sure if this affects any other cookie related files. The reporter cites the
files as having 0-length after this shut down. In out-of-disk circumstances it
seems that we don't want to write out the file, preferring to lose any settings
from the current session over losing *all* settings.

Comment 1

16 years ago
Isn't it cookperm.txt?  If this is dataloss, please set severity to critical,
and nominate for MachV.

Updated

16 years ago
Severity: normal → critical
Status: NEW → ASSIGNED
Keywords: adt1.0.0, mozilla1.0, nsbeta1
Summary: cookieperm.txt truncated when disk full → cookperm.txt truncated when disk full
Target Milestone: --- → mozilla1.0
Oops, you're right. Was just copying out of 86501. cheers. 

Updated

16 years ago
Blocks: 123929

Comment 3

16 years ago
Nav triage team needs info: is this really losing any data, and if so what is
the tangible impact on the end user?
Whiteboard: [need info]

Comment 4

16 years ago
Although I haven't tested with a full disk, I can well believe that this file 
will get lost.  And the cookies.txt file should suffer the same fate as well.

The impact on the end user is that all the sites for which he has given 
permanent YES or permanent NO for cookie accpetance will be forgotten, and he'll 
have to reply to the cookie-warning-box for those sites all over again.  If he 
has quite a lot of sites stored there so that his surfing has become a pleasant 
experience, he'll once again start being bombarded with annoying warning boxes.  
(Image permissions are kept in the same file, so all those will be lost as 
well.)

And if the cookie file has the same problem (which I'm pretty sure it must), 
then all the preference and state information that has been saved in cookies 
will be lost.

However, on the flip side, this problem is not that serious because few users 
will encounter it.  Even if they are running low on disk space, the fact that 
they will hit the zero limit just when the cookie files are being saved is a 
very unlikely event.

Comment 5

16 years ago
Nav triage team: nsbeta1+, adt2 rtm
Keywords: nsbeta1 → dataloss, nsbeta1+
Whiteboard: [need info] → [adt2 rtm]

Updated

16 years ago
Whiteboard: [adt2 rtm] → [adt2 rtm] custrtm-

Updated

16 years ago
Keywords: adt1.0.1

Comment 6

16 years ago
Mass removing adt1.0.0, and adding adt1.0.1 because, we are now on 1.0.1.
Keywords: adt1.0.0

Comment 7

16 years ago
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-

Updated

16 years ago
Keywords: mozilla1.1

Updated

16 years ago
Severity: critical → normal
Target Milestone: mozilla1.0 → mozilla1.1alpha

Comment 8

16 years ago
adt1.0.1-, and removing [adt2 RTM], as this has been nsbeta1- by nav triage.
Keywords: adt1.0.1 → adt1.0.1-
Whiteboard: [adt2 rtm] custrtm- → custrtm-

Updated

16 years ago
Priority: -- → P4
Target Milestone: mozilla1.1alpha → mozilla1.2beta

Updated

16 years ago
Keywords: nsbeta1-

Updated

16 years ago
Target Milestone: mozilla1.2beta → mozilla1.3beta

Comment 9

15 years ago
seems like we might want to have some sort of generic code for "safe" saving. 
other modules must suffer from the same problem.

Comment 10

15 years ago
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
Target Milestone: mozilla1.3beta → ---

Comment 11

15 years ago
also see bug 169220 - which sees this for mail filters.

Comment 12

15 years ago
.
Assignee: morse → darin
Status: ASSIGNED → NEW
Keywords: mozilla1.1
Whiteboard: custrtm-

Updated

14 years ago
Flags: blocking1.6?

Updated

14 years ago
Depends on: 228978

Updated

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

Comment 13

14 years ago
hmm... cookperm.txt no longer exists.  now we have hostperm.1 -- and perhaps
this bug still applies?  mvl?
(Assignee)

Comment 14

14 years ago
Yeah, the code that does the writing is basically the same. And afaik it is the
same for cookies.txt too. And likely other places. Would it be feasible to have
some service to take care making sure not to overwrite until there is a complete
new file?
Summary: cookperm.txt truncated when disk full → cookperm.txt / hostperm.1 truncated when disk full

Comment 15

14 years ago
maybe a special nsIOutputStream implementation?
(Assignee)

Comment 16

14 years ago
yeah, sounds good to me.
It just needs and extra method to indicate that writing was finshed and that the
old file can be removed (or backupped?) and the new file moved in place.
It only needs to work for local files ofcourse.

Comment 17

14 years ago
adding to my 1.7b task list.  i'll try to hash out an interface for this.  maybe
it can be a necko component.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.7beta
darin, did you ever get anywhere on this, and is it too late for 1.7?
QA Contact: tever → cookieqa

Updated

14 years ago
Keywords: mozilla1.0

Comment 19

14 years ago
i haven't made any progress on this unfortunately :(

i'm going to keep this on my 1.7 radar in hopes of finding time to work on it.
Target Milestone: mozilla1.7beta → mozilla1.7final
(Assignee)

Comment 20

14 years ago
In prefs, there is nsSafeSaveFile.cpp/.h. What if we move that into a more
general place (maybe inside network) and use that from other places that write
out profile information? That way, they won't overwrite old files anymore.
Maybe we can also add the symlink stuff
http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/src/nsBookmarksService.cpp#5441
has. If bookmarks need special treatment to follow symlinks, why not other files?

Updated

14 years ago
Target Milestone: mozilla1.7final → mozilla1.8alpha
(Assignee)

Updated

14 years ago
Depends on: 246675
Would like to get traction on this -- darin, can you give guidance to helpers?

/be
Flags: blocking1.8a2+
see bug 246675, which this one depends on.

Comment 23

14 years ago
brendan: mvl is all over this.  his patch for bug 246675 is exactly what we
want. after that lands, we just need to use nsISafeFileInputStream in more places.
blocking-aviary1.0, then -- go, mvl!

/be
Flags: blocking-aviary1.0+
(Assignee)

Comment 25

14 years ago
Created attachment 152539 [details] [diff] [review]
use nsISafeFileOutputStream

Patch makes permission code use the new nsISafeFileOutputStream code. Cookies
already do that.
Assignee: darin → mvl
(Assignee)

Updated

14 years ago
Attachment #152539 - Flags: superreview?(darin)
Attachment #152539 - Flags: review?(dwitte)

Comment 26

14 years ago
Comment on attachment 152539 [details] [diff] [review]
use nsISafeFileOutputStream

yeah, go mvl! r=me
Attachment #152539 - Flags: review?(dwitte) → review+

Updated

14 years ago
Attachment #152539 - Flags: superreview?(darin) → superreview+
(Assignee)

Updated

14 years ago
Attachment #152539 - Flags: approval1.8a2?

Comment 27

14 years ago
Comment on attachment 152539 [details] [diff] [review]
use nsISafeFileOutputStream

a=asa (on behalf of drivers) for checkin to 1.8a2
Attachment #152539 - Flags: approval1.8a2? → approval1.8a2+
(Assignee)

Comment 28

14 years ago
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Whiteboard: needed-aviary1.0

Updated

14 years ago
Keywords: fixed-aviary1.0
Whiteboard: needed-aviary1.0
You need to log in before you can comment on or make changes to this bug.