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] v1 patch
Comment on attachment 195931 [details] [diff] [review] v1 patch 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.
fixed-on-trunk, fixed1.8
or
