The problem is that the file is only ever created from scratch when a downloaded chunk is appended to the possibly-non-existent file, but nsIncrementalDownload::FlushChunk() short-circuits if the chunk to be written has a length of 0, and thus the file is never created. This problem is part of what makes nsUpdateService die when zero-sized MARs are served to it -- it makes the reasonable assumption that the file has been downloaded and created during onStopRequest, and an exception is thrown trying to access the downloaded file's size.
Created attachment 226514 [details] [diff] [review] Always create/truncate the dest. file during the channel's onStartRequest
Patch checked in on trunk; after some baking time I'd like to get it on trunk as well, particularly since the branch/trunk versions of these files are exactly synced.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 226514 [details] [diff] [review] Always create/truncate the dest. file during the channel's onStartRequest This patch will help make the update service more reliable when the server-side component is buggy and generates a zero-sized update. The risk of the patch is very small -- the only difference in behavior occurs if |mCurrentSize == 0|, which only occurs if the downloaded file doesn't exist or has an existing size of zero. In either case we're just creating the file if it doesn't already exist or truncating the file if it does, using code which has performed reliably whenever |mCurrentSize != 0| (which is every circumstance in which the component otherwise performs correctly).
Attachment #226514 - Flags: approval1.8.1?
*** Bug 317305 has been marked as a duplicate of this bug. ***
Comment on attachment 226514 [details] [diff] [review] Always create/truncate the dest. file during the channel's onStartRequest a=dbaron on behalf of drivers. Please check in to the MOZILLA_1_8_BRANCH and mark the bug fixed1.8.1 once you have.
Attachment #226514 - Flags: approval1.8.1? → approval1.8.1+
Checked in on branch.
You need to log in before you can comment on or make changes to this bug.