If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

nsIDownloader truncates large files (33MB) when a save location isn't specified

NEW
Unassigned

Status

()

Core
Networking: HTTP
P5
normal
10 years ago
13 days ago

People

(Reporter: Benjamin Smedberg, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-would-take])

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
Created attachment 269236 [details]
XPCShell testcase

I was trying to use nsIDownloader to save a 33MB file and kept discovering corruption issues. Turns out that if the following conditions are true, nsIDownloader will truncate the file size to something smaller (in my case 25599112 bytes):

1) the download is over HTTP (downloading from file: is ok; I haven't tried HTTPs or other transports)
2) nsIDownloader is initialized with "null" as the second parameter indicating that it should pick a default location. It appears that this location is within the HTTP cache
3) the file is large... I'm not quite sure how large

I've attached an xpcshell testcase. Please change the URL to a local server so that you don't kill my webhost, please.

Looking for usage of nsIDownloader in the tree, the only occurence in Firefox is in the JAR code. There are other occurrences in calendar for downloading ICS files.

I thought I would need this for bug 352762, but I've decided to go a slightly different route for a workaround.
Flags: in-testsuite?
> 25599112 bytes):

the default cache size is 50 MB; files in the cache can't be larger than half the cache size:
http://lxr.mozilla.org/seamonkey/source/netwerk/cache/src/nsDiskCacheDevice.cpp#692

that's somewhat unfortunate here...
Whiteboard: [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.