Closed
Bug 145557
Opened 23 years ago
Closed 21 years ago
cookperm.txt / hostperm.1 truncated when disk full
Categories
(Core :: Networking: Cookies, defect, P4)
Tracking
()
RESOLVED
FIXED
mozilla1.8alpha1
People
(Reporter: bugs, Assigned: mvl)
References
(Depends on 1 open bug)
Details
(Keywords: dataloss, fixed-aviary1.0)
Attachments
(1 file)
2.30 KB,
patch
|
dwitte
:
review+
darin.moz
:
superreview+
asa
:
approval1.8a2+
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
Isn't it cookperm.txt? If this is dataloss, please set severity to critical,
and nominate for MachV.
Updated•23 years ago
|
Severity: normal → critical
Status: NEW → ASSIGNED
Summary: cookieperm.txt truncated when disk full → cookperm.txt truncated when disk full
Target Milestone: --- → mozilla1.0
Reporter | ||
Comment 2•23 years ago
|
||
Oops, you're right. Was just copying out of 86501. cheers.
Updated•23 years ago
|
Blocks: profile-corrupt
Comment 3•23 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•23 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•23 years ago
|
||
Nav triage team: nsbeta1+, adt2 rtm
Updated•23 years ago
|
Whiteboard: [adt2 rtm] → [adt2 rtm] custrtm-
Comment 6•23 years ago
|
||
Mass removing adt1.0.0, and adding adt1.0.1 because, we are now on 1.0.1.
Keywords: adt1.0.0
Updated•23 years ago
|
Keywords: mozilla1.1
Updated•23 years ago
|
Severity: critical → normal
Target Milestone: mozilla1.0 → mozilla1.1alpha
Comment 8•23 years ago
|
||
adt1.0.1-, and removing [adt2 RTM], as this has been nsbeta1- by nav triage.
Updated•23 years ago
|
Priority: -- → P4
Target Milestone: mozilla1.1alpha → mozilla1.2beta
Updated•22 years ago
|
Target Milestone: mozilla1.2beta → mozilla1.3beta
Comment 9•22 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•22 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
Updated•22 years ago
|
Target Milestone: mozilla1.3beta → ---
Comment 11•22 years ago
|
||
also see bug 169220 - which sees this for mail filters.
Comment 12•22 years ago
|
||
.
Updated•21 years ago
|
Flags: blocking1.6?
Updated•21 years ago
|
Flags: blocking1.6? → blocking1.6-
Comment 13•21 years ago
|
||
hmm... cookperm.txt no longer exists. now we have hostperm.1 -- and perhaps
this bug still applies? mvl?
Assignee | ||
Comment 14•21 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•21 years ago
|
||
maybe a special nsIOutputStream implementation?
Assignee | ||
Comment 16•21 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•21 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
Comment 18•21 years ago
|
||
darin, did you ever get anywhere on this, and is it too late for 1.7?
QA Contact: tever → cookieqa
Updated•21 years ago
|
Keywords: mozilla1.0
Comment 19•21 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•21 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•21 years ago
|
Target Milestone: mozilla1.7final → mozilla1.8alpha
Comment 21•21 years ago
|
||
Would like to get traction on this -- darin, can you give guidance to helpers?
/be
Flags: blocking1.8a2+
Comment 22•21 years ago
|
||
see bug 246675, which this one depends on.
Comment 23•21 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.
Assignee | ||
Comment 25•21 years ago
|
||
Patch makes permission code use the new nsISafeFileOutputStream code. Cookies
already do that.
Assignee: darin → mvl
Assignee | ||
Updated•21 years ago
|
Attachment #152539 -
Flags: superreview?(darin)
Attachment #152539 -
Flags: review?(dwitte)
Comment 26•21 years ago
|
||
Comment on attachment 152539 [details] [diff] [review]
use nsISafeFileOutputStream
yeah, go mvl! r=me
Attachment #152539 -
Flags: review?(dwitte) → review+
Updated•21 years ago
|
Attachment #152539 -
Flags: superreview?(darin) → superreview+
Assignee | ||
Updated•21 years ago
|
Attachment #152539 -
Flags: approval1.8a2?
Comment 27•21 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•21 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Whiteboard: needed-aviary1.0
Updated•21 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.
Description
•