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.
Created attachment 195931 [details] [diff] [review]
Comment on attachment 195931 [details] [diff] [review]
should the IDL document that the caller can freely modify the file?
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.
ah ok, if we could ensure immuability that'd be great :)
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 ;-)
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.