308370 - nsIncrementalDownload::GetDestination should return a clone of nsIFile

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Darin Fisher]

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.

Comment 1

[Darin Fisher]

Attachment: v1 patch

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 195931 [details] [diff] [review]
v1 patch

should the IDL document that the caller can freely modify the file?

Comment 3

[Darin Fisher]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

ah ok, if we could ensure immuability that'd be great :)

Comment 5

[Darin Fisher]

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 ;-)

Comment 6

[Scott MacGregor]

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. 

Comment 7

[Darin Fisher]

fixed-on-trunk, fixed1.8