Closed
Bug 308370
Opened 20 years ago
Closed 20 years ago
nsIncrementalDownload::GetDestination should return a clone of nsIFile
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
RESOLVED
FIXED
mozilla1.8beta5
People
(Reporter: darin.moz, Assigned: darin.moz)
References
Details
(Keywords: fixed1.8)
Attachments
(1 file)
1.13 KB,
patch
|
Biesinger
:
review+
mscott
:
approval1.8b5+
|
Details | Diff | Splinter Review |
nsIncrementalDownload::GetDestination should return a clone of nsIFile
This is needed to workaround the fact that nsIFile implementations may cache
their stat caches. It is also similar to the way nsStandardURL::GetFile is
implemented, which allows consumers to modify the nsIFile that they get back.
Because internal string buffers are shared, the main cost incurred is that of
allocating a new nsLocalFile structure.
Assignee | ||
Comment 1•20 years ago
|
||
Attachment #195931 -
Flags: review?(cbiesinger)
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Flags: blocking1.8b5?
Target Milestone: --- → mozilla1.8beta5
Comment 2•20 years ago
|
||
Comment on attachment 195931 [details] [diff] [review]
v1 patch
should the IDL document that the caller can freely modify the file?
Attachment #195931 -
Flags: review?(cbiesinger) → review+
Assignee | ||
Comment 3•20 years ago
|
||
My thinking is that we may want to change this code in the future if we ever get
a nsIFile implementation that sucks less ;-) Like, it would be really cool if I
could hand out a reference to my nsIFile that was 1) immutable and 2) smart
enough to return the actual file size when requested.
Comment 4•20 years ago
|
||
ah ok, if we could ensure immuability that'd be great :)
Assignee | ||
Comment 5•20 years ago
|
||
Yeah, I've always wanted a way to mark a nsLocalFile instance as immutable.
Something similar to the way nsStandardURL works would be nice. But, heck...
it'd be nice if we even used nsStandardURL's support for immutability ;-)
Updated•20 years ago
|
Attachment #195931 -
Flags: approval1.8b5+
Comment 6•20 years ago
|
||
this looks low risk so approving for the branch but we should let it bake on the
trunk for a couple days just to be safe.
Flags: blocking1.8b5? → blocking1.8b5+
Assignee | ||
Comment 7•20 years ago
|
||
fixed-on-trunk, fixed1.8
You need to log in
before you can comment on or make changes to this bug.
Description
•