Closed
Bug 164189
Opened 23 years ago
Closed 22 years ago
nsLocalFile::GetParent fails if the file has been deleted
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.4beta
People
(Reporter: sfraser_bugs, Assigned: ccarlen)
References
Details
(Keywords: topembed)
Calling nsLocalFile::GetParent on an nsLocalFile, when some other code has
deleted the file that it points to, returns an error. It should probably do
something like fall back on a full path.
|
Assignee | |
Comment 1•23 years ago
|
||
Rather than representing the file spec as FSRef + non-extant path, it could be
represented as a CFURL. If the base FSRef is deleted by some other file object,
we're doomed. Storing it as a CFURL would also make InitWithPath/GetPath
operations (which are hit heavily) faster.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2alpha
|
|
Assignee | |
Updated•23 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
|
|
Assignee | |
Comment 2•23 years ago
|
||
Mass move of 1.3a bugs -> 1.4a.
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
|
Reporter | |
Comment 3•22 years ago
|
||
This bug is affecting xpti registration, as well as file handling for downloads.
It's made worse by the fact that the nsDirectoryService caches nsILocalFiles, so
if any of those become invalid, lots of file operations fail.
This bug was also the cause of bug 192124.
Severity: normal → major
|
|
Assignee | |
Comment 6•22 years ago
|
||
Fixed by checkin of bug 164396.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•