New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 60 users
Status: Fixed
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

issue 68359

Sign in to add a comment
HTTP Download stops at 2GB when saving the file on another NTFS drive.
Reported by, Jul 17 2011 Back to list
Chrome Version       : 12.0.742.122
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: not tested
  Firefox 4.x: not tested
     IE 7/8/9: not tested

What steps will reproduce the problem?
1. Download the opensuse iso from a http link
2. choose to save the iso on another internal drive on root \ (also ntfs formated!)
3. Download starts.

What is the expected result?
Download finishes at ~4GB

What happens instead?
Download stops at 2,159,612,663 Bytes ! No error message. It just stops downloading.

Please provide any additional information below. Attach a screenshot if

UserAgentString: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122 Safari/534.30

Labels: -Area-Undefined Area-Internals Feature-Downloads
Andy: I suspect this'll be taken care of by the file error reporting you're currently doing, but I wanted you to be aware of it.  (And if you disagree that it'll be taken care of by file error reporting, please let me know.)

Hmm, according to this:

FAT has a 2GB limit on file size, but not NTFS.

AFAIK, Chrome has a 2GB limit on write size, but not on file size.

With the file error reporting I'm working on, we should at least get an indication of the problem rather than silently failing.  From your report, I assume it works on your primary drive.  Is this correct?

FYI 2,159,612,663 bytes is 12,129,015 bytes over 2GB.

So, it's probably not related to any 2GB file limit.

Yes, the download works if I save to my default download folder in my user account on Windows 7. But it will fail if I select another drive.

Note: Downloaded the file succesfully with Firefox 5 on this other drive.
Blocking: 68359
Comment 6 by Deleted ...@, Sep 19 2011
I'm having this same problem with Google Chrome 14.0.835.163 m running on Windows 7 SP1 64-bit. My Downloads folder is located on an NTFS-formatted drive with plenty of free space.
Comment 7 by Deleted ...@, May 21 2012
I'm on Ubuntu 11.04. It goes to 2GB and stops with the Windows 8 CP ISO. I've tried it at least 10 times, and if it starts at all, it will only go to 2Gb and claim to be done. The file is 2.52GB. It wont download on my Vista machine at all using IE9. I'm using Chrome on Ubuntu, and have tried Firefox and Chromium, which don't work at all. 

Any Ideas?
Can anyone get a network internals dump for this with a recent version of chrome (20.* or 21.*)?  That'd probably get us a lot close to what's going on.  

Instructions for getting a net-internals dump can be found at

Comment 9 by, Jun 2 2012
I'm happy to help but Chrome keeps stopping the recording script because it uses too much memory (only after a few minutes). Any advice other than just waiting for it to get close to 2 GB which is going to be a pain to get just right?
Alright, I can't recreate this right now. I'm running 20.0.1132.21 beta on Windows 7 SP1 64-bit. Maybe it's gone in the latest Windows builds?
Hmmm.  Maybe, though I'm not offhand aware of any fixes that would have made this go away.  Let's leave the bug open for a bit, and if it doesn't recur within a couple of weeks I'll close it.
Comment 12 by Deleted ...@, Jun 17 2012
Same issue for me...  It goes to 2GB and stops with the Windows 8 CP ISO. It will only go to 2Gb and claim to be done. The file is 2.52GB.
#12: Are you downloading to a local disk?
Blocking: chromium:68359
Comment 15 Deleted
Comment 16 by Deleted ...@, Aug 6 2012
Having this issue, myself, the past few weeks.  I'm running 21.0.1180.60 m
Comment 17 Deleted
Comment 18 by, Aug 6 2012
Labels: checkedk
Project Member Comment 19 by, Aug 10 2012
Status: IceBox
Closing old bug as obsolete. Please file a new bug (with details) if this problem is still occurring for you.
Closed, obsolete? With a comment from 4 days ago saying still an issue 

Status: Untriaged
There's enough activity on this bug for me to think it belongs in Untriaged (rather than Unconfirmed) and therefore shouldn't be IceBoxed.

Another request for anyone who's still seeing this: Could you get a net-internals dump, but before trying to reproduce the bug, go to the "Capture" subsection of about:net-internals and click "Discard old data under memory pressure"?  I'm not sure that'll give the data we need, but it might, and it's (I hope) fairly simple to try.  Thanks!

Comment 23 by Deleted ...@, Sep 13 2012
Got this twice in a row today. Attached is the net-internals dump.

Version 21.0.1180.89
815 KB Download
Labels: MS-24
Status: Assigned
@wtyler...: Unfortunately, that net log didn't have the info I was looking for--it at least looks like the interesting data was pushed out by the recording of the individual byte transfers.  

Would you be willing to try another time, but in collecting the net-internals do the following?:
* Open a single about:net-internals window.  Make sure it's your only net-internals window (otherwise the override you're about to do won't work).
* From the "Wrench" menu (upper right portion of the screen, to the right of the Omnibox) choose Tools -> Javascript Console.
* At the javascript console, type "g_browser.setLogLevel(2);" and hit return.
* Close the javascript console ("X" in the upper left hand corner of the console).
* Reproduce the problem and send the log dump as before.

Thanks/sorry about this.  

Labels: -MS-24
Can anyone who is experiencing this problem provide a net-internals dump as described in c#25?  I'd like to fix this, but at the moment I'm at a dead end.

Labels: Action-FeedbackNeeded
Chrome Version: 24.0.1312.14 beta-m
OS: Win7 Ultimate x64 (7601.17944.amd64fre.win7sp1_gdr.120830-0333)

This issue is quite weird and I'm not the best for writing explanations, but I'll do my best to describe how to reproduce the issue.

Begin a download of a file size greater than 2gb over HTTP
The download footer bar thingy appears with the options like 'Show all downloads' and the far right 'X' button to hide the bar.
If you click Show all downloads OR the X, the issue DOES NOT occur.
However, if you simply don't touch anything and let the download progress, it will actually stop at 2gb, claim that the download completed, and rename the file from the .crdownload whatever name to the proper file name, despite not having actually downloaded the full contents of the file.

Hopefully this helps shed some light on the issue.
@anonymousx: Any chance you could follow the directions in c#25 (also see for the basics of providing a net-internals dump).  I'm not able to reproduce this locally, so I'm dependent on other folks for detailed debugging info.

Status: WontFix
Closing for lack of data :-J--I'd like to fix this, but I don't have a way to move forward.  If anyone runs into this again, please open a new bug, and include network details as in c#25.  Thanks!
 Issue 166358  has been merged into this issue.
 Issue 168502  has been merged into this issue.
Status: Assigned
Re-opening as the bug on this issue that has the most detail, so that I can dup a couple of other issues to it.

Note to self (or anyone else on Chromium that picks this bug up: The basic question is where chrome thinks the close signal is coming from.  I don't believe there's any file system error that won't result in sending an error back up to chrome, and it isn't a matter of the file system blindly swallowing the bytes since one of the net-internals dumps posted on one of the dups of this bug shows the total bytes written as being near 2GB.  But there's no obvious reason why the network would suddenly stop sending bytes after 2GB either (maybe some form of network throttling?).  

Chrome does silently swallow CONNECTION_CLOSED errors when the total bytes received isn't the same as what the website advertised, since there are a lot of websites that lie.  So this could be a server problem.  But the size at which the download ends is suspicious.
Comment 34 by, Jan 31 2013
I just experienced this issue last night with a Centos DVD download (HTTP)onto a 250gig SSD drive formatted NTFS.  The download kept completing at 2gigs which was far short of the 4gigs it should have been.  There was no error and did display as completed.  I tested the drive by copying over a 4 gig file and it was fine.  So it was something Chrome was doing.
@philw64: Thanks much for the additional report.  Any chance you could follow the directions in c#25 and attach the log?

 Issue 166358  has been merged into this issue.
Just experienced this today downloading a Windows 8 Pro and Server 2012 ISO from the Microsoft Volume Licensing Service Centre.  Download just stops "successfully" at 2Gb written even though it's a 3Gb file.
 Issue 166358  has been merged into this issue.
Comment 39 by, Feb 17 2013
This bug was reported on Jul 17, 2011 and is not fixed yet... How is that possible? :-(
Comment 40 by, Feb 17 2013
And also, this bug is not only related to Windows OS. It's present on Linux too.
Reminder: I'm still waiting on someone providing me more info on the bug, as per the request in c#25.
Comment 42 by, Feb 28 2013

Can't you reproduce the issue?

Maybe we are talking about different things. I CAN download files bigger than 2GB by a normal HTTP download.
The problem happens when I try to download a file bigger than 2GB in background, which is stored into "$HOME/.config/chromium/Default/File System/001/t/00/" directory, and, when the download finishes the window who asks you about "where to place the download" appears, and moves the temp file from that directory to the directory you choose. Of course, the download never finishes because it's stopped at 2GB, and the "where to place the download" window never appears.

Have you tried to reproduce the issue in that manner?
@peratu: I have not to date been able to reproduce the problem; I'd be ecstatic if I could.  But I'm not sure I follow your reproduction instructions; what does "downloading a file bigger than 2GB in the background" mean?   That path appears to be used for the file API, which allows javascript to create and access sandboxed files on the user's file system.  Are you running a web app or visiting a web page that uses that API?  How does it do the download?  
I consistently had the problem trying to download the Windows 7 64-bit home edition ISO from Microsoft. Had to use IE to download it successfully.

This is what I was trying to download but would stop at 2GB in Chrome:

@mikeberthold: Just downloaded that ISO successfully :-{.

Just a quick note for the record that @peratu has provided me with a link offline.  The link appears to be downloading under page control to a file controlled through the file API; my presumption is that once the data is all on the local file system, the chrome download mechanism will be used to save it to the local file system.   (This based on watching a file in Default/File System grow, the lack of any download shelf interaction, and the comments above.)  We'll see what happens.

Project Member Comment 47 by, Mar 9 2013
Labels: -Action-FeedbackNeeded Needs-Feedback
Project Member Comment 48 by, Mar 10 2013
Labels: -Area-Internals -Feature-Downloads Cr-Internals Cr-UI-Browser-Downloads
Thanks for all your efforts guys but just to re-iterate:
1. the limit is 2.15GB
2. I'm on MacOS X (10.8.2)
3. I'm not saving to an external drive just my hard drive (different folder
locations depending on subject of mp4 to be downloaded)
I've suspended my subscriptions to sites for these downloads as it's a
waste of time & money until this issue is fixed.


@joestoner49: Can you give me some example links for your downloading?  When you download, does it create an entry on the download shelf immediately?  (@peratu's example does not because it's doing web page mediated download to the filesystem API and only once that completes downloading to the local file system.)

There is no delay in starting the download where ever I decide to store it;
there does not appear to be any other activity.
I'm using a MacBook Pro running Mountain Lion and the downloads fail at
2.15 GB NOT 2GB
@joestoner49: Thanks!  Any chance you can follow the directions in c#25 and tell me what you find?

Comment 53 by Deleted ...@, Apr 18 2013
I am running Version 26.0.1410.64 m

I tried following the directions in c#25 but when I type g_browser.setLogLevel(2); into the javascript console it returns undefined.

I am proceeding anyway and will upload the log dump when it completes.
#53: Is there a log available?
Hello, I'm also still having problems downloading files larger then 2 GB (the partition I'm using are ALL NTFS)
I do kow my 'home' drive is on a network share (Windows XP/Windows Server 2003)

Using Chrome version 27.0.1453.116 m

I'll try to created a log ASAP
Hi thanks for letting me know that I'm not alone in this weirdness my
problems are on a mac but I do have this old XP which I could use if Google
can find where the fault is.
Please keep me in the loop.
Comment 57 by Deleted ...@, Aug 21 2013
I also encountered this problem while trying to download a file > 2GB from Amazon cloudfront servers. I open a new tab, paste the link in the address bar, and hit Enter.
Twice the download has been incomplete, different sizes each time. One time was 1916208128 bytes (already deleted the other file). Full file is 2123802785 bytes. One time Chrome did get the whole file -- strange to be so inconsistent.

The second time I tried following the steps in #c25, and when the download "finished" the net-internals tab was unresponsive. So unfortunately I don't have a log.

There is definitely a problem. It also happened at a customer's site using chrome.
No problems downloading the file with Firefox. The file in question is a private beta of our product.

Browser: Chrome Version 28.0.1500.95 m
OS: Windows 7 Pro SP1 64-bit

For myself I don't really care if Chrome/Chromium can download large files, I prefer ff, but Chrome has a large user base now, and things like this should just work. 
Can't agree more Mr Smith:
... and things like this should just work!!!!!!!!!!!!!!!!!!!!!!
I am getting this issue too trying to download large ISO files hosted on Amazon Web Services. Downloads stop at 2GB.
Deeply disappointing that Google can't fix this!
Even more worrying is that they don't seem to care:((
I can reproduce this problem locally (downloading file from localhost). I've tried both Apache and Microsoft IIS, so it does not depend on server. I've tested it on Windows 7 and Windows 8.
It's exactly 50% chance that download completes succesfully and 50% chance that download stops after 2GB (my downloaded file size was 2147484402 or 2147487474 bytes).
482 KB Download
#61: Thanks for the log! That was very helpful.

rdsmith: My current theory of what's going on is as follows:
- This could happen if Chrome has a sparse cache entry for the resource.
- HttpCacheTransaction issues a request for the range (cached_offset ... cached_offset + (2^31 - 1)) (see
- Once we start receiving a response, RDH attaches the DownloadResourceHandler to the ResourceHandler chain.
- DownloadResourceHandler calls StopCaching().
- Because the request is not being cached, HttpCacheTransaction doesn't issue a request for the next range. Effectively terminating the download prematurely.

The requests from the log are:
C->S:                             --> GET /t4.iso HTTP/1.1
                                      Range: bytes=3827-3827
                                      If-Range: "d6d35110c1c1ce1:0"

S->C:                             --> HTTP/1.1 206 Partial Content
                                      Content-Type: application/octet-stream
                                      Accept-Ranges: bytes
                                      ETag: "d6d35110c1c1ce1:0"
                                      Content-Range: bytes 3827-3827/2500000000
                                      Content-Length: 1

C->S:                           --> GET /t4.iso HTTP/1.1
                                    Range: bytes=3827-2147487473
                                    If-Range: "d6d35110c1c1ce1:0"

S->C:                           --> HTTP/1.1 206 Partial Content
                                    Content-Type: application/octet-stream
                                    Accept-Ranges: bytes
                                    ETag: "d6d35110c1c1ce1:0"
                                    Content-Length: 2147483647
                                    Content-Range: bytes 3827-2147487473/2500000000

Comment 64 by Deleted ...@, Nov 21 2013
Just wanna know if this issue has been repaired? Cause i also face this problem this morning when I download the ISO file which size is 3.3GB from MS server 
Comment 65 by Deleted ...@, Nov 21 2013
 Chrome version is 31.0.1650.57 m
and OS is WIN 7 64-bits SP1
Comment 66 by, Dec 19 2013
same problem here
chrome Version 31.0.1650.63 m
win seven PRo 64 bits

Trying to download a large file (~4Gbytes), no problem with Firefox but with chrome the download can finish well or stop at 2Gbytes. During the last tests, seems the problem occurs 1 time each 2 downloads (cf attached file).
Files names ending with (number) came from chrome
Files names ending with FFnumber came from FF

thank you

38.8 KB View Download
Comment 67 by, Dec 19 2013
the corresponding net-intenals log file
6.3 MB Download
I also faced this issue yesterday while downloading Hortonworks+Sandbox+2.0+VirtualBox.ova - was hoping better job by Chrome browser as this issue was reported very long time back.
Comment 69 by Deleted ...@, Jan 26 2014
I also had this problem today (twice in a row) when trying to download a Windows 7 ISO from Microsoft (

Comment 70 Deleted
This issue is still present even on a Mac. Chrome claimed download success at exactly at 2GB (2147484797 bytes) when attempting to download CentOS 7 ISO (6.6 GB). Had to resume the download with curl from a shell. It appears this issue is not related to NTFS and is, instead, related to something specifically within all Chrome versions.
Comment 72 Deleted
Comment 73 by Deleted ...@, Aug 10 2014
same thing here, downloaded a 3.7GB archive, failed 3 times at 2GB, really nice when dealing with quotas.... please fix this, we're in 2014... this was working fine back in netscape!
Labels: -Pri-2 Pri-1
Comment 76 by Deleted ...@, Aug 27 2014
3 years later and this bug is still present.
I'm using Chrome 36.0.1985.143 and downloading nearly everyday files over 2GB and once in a while the download stops at 2GB without any error reported.
I always download to the same location: a micro SD card formatted in exFAT.
I can download files larger than 2GB, but it's just frustrating to see that it's not always working.
Comment 77 by Deleted ...@, Sep 15 2014
Come on! I'm working with big video files every day. When we upload it for other people to download it we always have to mention that they can't use Chrome. Other browsers work perfectly but not Chrome.. It's 2014 people... I cannot believe this problem actually still exist.
Very annoying. I thought it was the website I was downloading from that had the problem... Turns out it was Chrome. =(
Why isn't this fixed yet?
Because nobody has found the bug yet, or indeed proven that it *is* a Chrome bug at all.

IMO, every single instance of this behavior over the past years has been caused by something in the path between Chrome and the origin server. Things I can think of are firewalls that reassemble packets or transparent caching proxies. ISPs do strange things these days.

If you want to help, reproduce the bug with *nothing* more intrusive than a switch between you and the server, or prove that a different browser (or wget, for example) does not truncate the download. To exclude effects of dynamic routing etc., please repeat the latter test at least four times (with consistent results, of course).
When multiple people have repeated failures using one browser and then it immediately works using any other browser (whether it is IE or Firefox), then that clearly points to a Chrome specific issue. 

Now, it's obviously not something that happens often and is intermittent, which makes it difficult to diagnose and fix, but nothing is solved by inventing other possible issues that are immediately discounted by the fact everyone having the issue works around it by switching browsers (and not ISPs, proxies, firewalls, or any other possible factor).
Well, it does work in IE and Firefox, without switching any other variable, so Chrome is clearly the issue. This is obvious, as Chrome says the download is complete, but it isn't. This was tested using the Windows 10 preview.
The bug is Confirmed on OS  X 10.9 with 37.0.2062.124 and the download works fine in Firefox and Safari
Status: Started
 Issue 421396  has been merged into this issue.
Comment 86 by, Oct 9 2014
If ssue 421396 is a duplicate then its title should be changed. I'm on OS X so no NTFS here, just regular HFS+.

Comment 87 by, Oct 15 2014
I have recently tried to download a Windows Preview and a RHEL Eval with Chrome 38.0.2125.101 32-bit and the transfer stopped multiple times at 2GB on different 64-bit systems from different networks. A while back on the same machines a Chrome 37.0 32-bit had no problem downloading the same ISO files apparently distributed from and from This CDN could be of interest in the issue since other large file transfers are working just fine with the current version of Chrome. So until a permanent fix it might be worth switching chrome://flags/#enable-download-resumption and restarting the browser before the next Akamai grab.
Comment 88 by Deleted ...@, Nov 19 2014
Bug still there, i downloaded this file (which is in fact Windows 7 SP1 U 64 Bits). Its size is 3GB, but download stops at 2GB. The bug is still there, 3 years after.
Seriously, i think Chrome is way better than other, but this. This is really dissapointing for a 2014 web browser.

This happend 5 times in a row, actually it always happen for me if the file is more than (around) 2GB.

Proof of today's failure with exact size of file after download ends in attachment
99 KB View Download
Comment 89 by Deleted ...@, Nov 19 2014
Me again, can't edit posts here ? Forgot to say i'm using "Chrome Version 38.0.2125.111 m"
But i updated it to "Version 39.0.2171.65 m" some minutes ago, i'll try again but i'm not optimist about it.

Anyway, in the meantime i downloaded the file through Firefox (v31.0) and it worked at first try.

Chrome is clearly the problem in this case, no doubt about it. I know that downloading such files using web browsers is not the best, but it shouldn't be a problem either !
Comment 90 by, Nov 20 2014
I no longer have this problem on OS X 10.10.1 in Chrome 39. I assume that it's because Chrome 38 was 32-bit and Chrome 39 is 64-bit. There already is a 64-bit Chrome Linux version so it seems Windows Chrome users are suffering because it's still 32-bit?
Comment 91 by, Nov 20 2014
I experienced this issue yesterday when trying to download the KNOPPIX DVD using the 64-bit version of Chrome 39 on Windows (tried downloading two or three times and then gave up). Would following the steps from #c25 help, or are there other steps now that would help?
 Issue 166634  has been merged into this issue.
Sod Merging it FIX IT!!!!!!!!!!!!!
Comment 94 Deleted
Comment 95 by Deleted ...@, Feb 12 2015
I used to use firefox until a flash problem emerged. Now I'm gonna switch back. Mozilla fixed the problem rather fast but this issue is ancient and no one seems to care.

Chrome version: 40.0.2214.111 m
Win-7 Professional 64-Bit Build 7601
In case it matters somehow, my downloadspeed is between 5.0 and 6.0 mb/s nearly all the time.
Comment 96 by, Feb 25 2015
This is ridicules that Google ignores to fix such popular issue(download 2G limit) for years! I've switched to other browser. By the way, IE, Firefox and 360 w/o any such problem at all.
Comment 97 by Deleted ...@, Mar 6 2015
have same issue today, downloading 3.5g file from microsoft windows 10 ISO... stops dead at 2gigs each time i try.
Why can Google NOT fix this??????
Comment 99 by, Mar 12 2015
>>  Why can Google NOT fix this??????

Well, given how long the problem has been outstanding, and given that the precise limit of truncation shows that this can't be dismissed as a rare or random glitch, it is perfectly clear that they neither care nor can be bothered to do anything about it.  

Clearly a browser with such an issue cannot be relied upon for any important work, especially where one might need to download large files, and the fact that such an issue has been noted (on this page alone) for nearly 4 years implies that the browser is unfit for serious work of any kind — you certainly wouldn't want to support this in any large-scale deployment: 
    Q:  "I can't download large files, what am I doing wrong?  How can I solve the problem?"    
    A:  "Well, first you will need to get a different browser..."   
    Q:  "So why did you give me a broken browser in the first place???"   

I have certainly cited this page to corporate clients as a clear and simple reason why they should no longer consider Chrome a viable option — there are actually many other reasons, but this issue is particularly easy to cite and to explain.  I'm not writing this as a knocker:  I was an early adopter and used and recommended Chrome from its earliest days —I want to like it— but this is no longer a feasible position.  

I don't think the number of desktops affected yet runs into 100,000s, but I can certainly say that this is part of the reason for Chrome being ruled out of deployments affecting several tens of thousands of desktops at a time, in my experience alone.  It's a drop in the ocean, but on the other hand, there might be 100 or even 1000 other people reading this page doing the same kind of things as me...   What I can say is that such decisions are unlikely to be seriously reviewed within less than  four or five years, and that a history of long-term failure to fix an issue (such as we see here) means that a decision to exclude a product from consideration is likely to persist through several cycles of review.  

Personally, I'd be far more likely to recommend even IE than Chrome these days (though there are many other reasons behind that than just this issue);  I'm sad about that —Chrome *ought* to be a far better choice— but we can't just ignore the facts.  

I agree withthe last post. Same reason I didn't use Firefox in the enterprise before. See:
What the heck are Google thinking of! Consigning a fine browser to the
Comment 102 by Deleted ...@, Mar 19 2015
I ran into this problem and it killed many hours of an otherwise productive workday.  Chrome is content with stopping the download at 2.15 Gig.   I forgot that it had happened a few years ago but  I think I ended up using FF to get it done then too.

This is ridiculous with no fix in that many years.

Google could have at least made an official response that said something like:  "In the likely event you should ever need to download a file that has a size greater than 2.15 Gb, please use our competitors browser Firefox, downloadable from
I have another problem with Chrome:
Mac OS X
Activity Monitor shows SEVEN iterations of Google Chrome Helper hogging
over 1.2 GigaBytes of RAM. MORE than kernel_task (1.12G)!!!

Wonder if Google care about this careless, profligate use of memory???
c#103: If you have an unrelated problem, the best bet is filing a new bug (  Feel free to cc me or send me the bug number, and I'll try to make sure it gets to the right people.

FWIW, "Google Chrome Helper" is the name of the renderer process, and the size of those processes are pretty much under the control of the web page they're visiting.  You can look at the Chrome Task manager (triple line menu on the right side of chrome -> More Tools -> Task Manager) to match up piggy renderers with web pages, and killing those web pages will recover the memory.  

Having said that, yeah, we're working on Chrome's memory usage.

Labels: -Needs-Feedback -Cr-Internals
As for this issue, we are now actively working on it. Apologies for the frustration this issue has been causing for an unjustifiably long time.

Comment 106 by Deleted ...@, May 12 2015
Same problem here : win7 64 pro with chrome 42.0.2311.135
Tried several times to download Windows 10 preview from Microsoft links, and files never went more than 2 149 131 687 bytes.
I am a huge fan of chrome, but it seems the QA is degrading over time : chrome use to be the fastest, and now I feel others (IE ?!) to be faster. Chrome use to work all the time for everything, and now I can't get a file more than 2 Gb, seriously. And recently, pointer stopped working in VirtualBox running Linux....
Comment 107 by Deleted ...@, May 12 2015
Not related to NTFS but I also see the 2GB (plus some bytes) limit intermittently using Chrome on both Windows (42.0.2311.135 m) and Mac (42.0.2311.135 (64-bit)). Server-side debugging (Debian/Apache) suggests that the 2GB limit (plus some bytes) happens when Chrome uses a HTTP Range-request to download the file. When it does use a Range request Chrome consistently starts with a first chunk of 2GB but fails to fetch additional chunks to complete the full download. Typical sequence:

1) [ client gets/has the first few bytes ]

2) Client does the 1 byte check:
Client:  Range: bytes=2208-2208 
Server:  Content-Range: bytes 2208-2208/3435134976

3) Client requests first chunk of 2G
Client: Range: bytes=2208-2147485854
Server: Content-Range: bytes 2208-2147485854/3435134976

4) Client assumes download is finished, ignoring the rest of the file.

When Chrome doesn't use Range requests (one in two downloads ?) all 3435134976 bytes are downloaded.

 Issue 488198  has been merged into this issue.
Is it possible to prevent Chrome using Range requests?
Ran into this today, again, trying to download the Windows Server 2012 ISO on my CentOS 7 machine.  4.2 GB file, showed it had 15 minutes left, I went to another workspace to read an email, came back, and Chrome claimed the download had finished without error.  The actual file size was 2,147,484,759 - a far cry from the 4.2 GB it's supposed to be.  I re-ran the download and it worked fine the second time, file size of 4,542,291,968.

I wouldn't even care so much if it would just say the download failed.  The problem is it claims the download finishes fine, it renames it to the proper name, etc.  Unless you pay attention to the download the entire time to make sure it doesn't abruptly end without warning or error, you have no idea if your download is complete or corrupt.  I can't spend my day watching the download bar to make sure it goes all the way to 100% before finishing, I have better things to do with my time.
It seems that Google don't care about this pathetic and annoying fault. It
seems that Chrome can select two "ways" of downloading where one has the
limit and the other don't. It would seem to be a trivial coding exercise to
give the user the option to lock out the limited version with a pull down!!!
How is it that this problem still exists after 4 years of having been reported?

This is embarrassing.
Can someone please just add a file size check to the routine used to download files until it gets fixed? User experience is everything.
It's not embarrassing it's PATHETIC!!!!
Especially when it is known that Chrome randomly choses one of two methods
to download and only ONE of which results in this c rap!
Sorry folks but 4 years is more like Microshit than Google!:((
I've been watching this bug for some years now. Just now I've been bitten by it for the second time, while downloading a large ISO. The first download attempt failed because the DSL line was disconnected remotely, and the second one stopped close to 2 GiB.

I finished the download with wget -c.
wget -c ????
>> Sorry folks but 4 years is more like Microshit than Google!:((

​No, I'm afraid this is very much Google.  I want to like what they do​, but they are very pleased with themselves to make endless oh-so-clever changes ​that are often simply disruptive and irritating​, but they are actually completely useless when it comes to making sure the basic essentials work consistently and reliably.  

You can find dozens of show-stoppers like this on Google code:  check out, for example
​"​Chromecast cannot attempt to handle changes in HDMI refresh rates since it is very hard to accurately identify the incoming frame rate.​"​

​It may be "very hard", but many ultra-cheap Chinese sticks seem to manage just fine, and a the manual switch they refuse to even consider would be completely trivial!  This rather demonstrates the point: the user's preference ​—a simple manual option— is of no importance to Google, they'd far rather do something clever and complicated to second-guess what should happen, even if they completely fail to make the device usable as a result.
I was simply asking what "wget -c" meant?
It's a commandline to download files from Unix / Linux. It has nothing to do with Chrome:
Comment 120 by Deleted ...@, Aug 26 2015
Google no longer cares for the masses people! Go elsewhere! I switched back to Classic Opera 12.17 because the newer Opera uses the same Chromium shit as the rendering / browser engine! I hate Chrome / Chromium! Hate Vivaldi too! It also uses the same Chromium engine! Common guys! If I want to open 30+ tabs, whatever power / memory my systems, gets sucked by this one monster application! Stop using this shit and feeding google all your data / profile and browsing habits.
Hear what you say what about FireFox?
Comment 122 by, Sep 4 2015
I just love the way people complain and criticize Chrome on the bug tracker. Yeah, it's annoying, but I just started using curl. It's faster than any browser downloader anyway.
You are right! I myself switched to smoke signals, no more 2GB limit anymore!
Still a problem in Chrome 51.0.2704.79 on MacOS 10.11.5, trying to download Win 10 ISO direct from MS.  curl -O worked.  I'm disappointed (though not surprised) that this isn't in a Chromium regression test.
Google don't care mate:((
Found this previous bug I wanted to link:
Large Mac downloads work - for example, I successfully downloaded Xcode 8, a 5.5Gb file, using Chrome Mac 50.0.2661.102. I'm sure there are many, many other successful downloads larger than 2Gb.

Can someone share a link to a large file that fails to download on the Mac? And what kind of connection do you have to the Internet?

Status: Assigned
I think "started" is the wrong status for something with no real update in 15 months.
> I think "started" is the wrong status for something with no real update in 15 months.

That's how coders deal with bugs they don't want to deal with.

They shift the status around and re-assign it to different groups or individuals to make it look like someone's working on it, so that when their manager glances through their task list either they don't see the bug assigned to them or it looks like work has been done.

I predict the owner of this bug will wait a few months until people stop commenting and close the bug as "won't fix" or "can't replicate" or "not enough info" or they'll come up with some excuse to accuse the person who submitted it of not providing enough info.
They know how to fix it as it has TWO download modes which it choses at
random with NO notification regarding the 2GB limit on one! It then reports
the download complete!!!!!
Care to elaborate, joestoner?
Assignee here. I think an explanation is warranted here before I start work on this again.

This behavior isn't trivially reproducible since it requires the cache to get into a rare but correct state. However, those affected will find it reproduces reliably when trying to download a specific resource.

I started a CL to address this issue here right around the time I marked the issue as "started". However, it fell off the table due to a number of reasons.

This bug is caused by several gaps in the state machine implemented in HttpCacheTransaction which fails to push the request past the 2GB mark *if* there is a partial cache entry suck in the cache for the same URL. In other words, if you try to download something once and stop for some reason, *and* if this results in a partial cache entry for a prefix of the file in the disk cache, then the next time you try to download the same URL, the network stack will erroneously report the request as having completed when it passes the offset at 2GB + length-of-cached-prefix-block.

In the CL linked above, you can see these shortcomings being referred to as being part of the "StopCaching" mechanism in HttpCacheTransaction. This is a feature of the cache infrastructure where it can decide to avoid writing a resource to disk partway through reading it off the network. You need this to prevent a multi-gigabyte resource from being written to disk as a download and again as a cache entry. Aside from being wasteful it may also cause useful cache entries to get evicted. However, the way it is currently implemented causes the aforementioned behavior.

Unfortunately, said mechanism is entangled with a number of other features of HttpCacheTransaction making it difficult to fix the logic bug in isolation. In fact one would argue that there are other underlying issues that, if addressed, would make this issue go away as a side-effect. The desire to implement the full and correct but difficult fix unfortunately cause the fix to bloat and get dragged on until it got pre-empted by other urgent work. This wasn't the correct way to handle this issue.

So, I'm going to revive work on this. And this time I'll focus on getting a shorter term mitigation until several related issues are addressed making it possible for the correct fix for this issue to finally land.

Sorry Wes Im not a coder, just a frustrated user, I raised this years ago
and finally got a reply which elucidated the two modes but as the bug has
been passed around threads I've lost the specific reply, but I'll keep
looking mate.
Hi assignee.  

Firstly, good luck in sorting the issue out and getting the underlying issues fixed.  


This is a critical bug in basic functionality.  It has been extant on your tracking system for OVER FIVE YEARS, in which time it's been closed twice and seven other bugs have been closed by being merged with this one which still hasn't been fixed!  
It had already been assigned twice, the first time in 2012.  

I'm afraid the conclusion is that Chrome —and other Google products— simply can't be relied upon for serious work.  

Not because of this one bug, but because Google apparently doesn't have any adequate corporate governance in place to track and close down show-stopping bugs in a flagship project.  

This is not an isolated case:  for example, it took over a year to add a simple manual switch to allow Chromecast users to watch media at 50Hz (something ultra-cheap no-name Chinese sticks managed flawlessly)

Once such a situation becomes established, it is no longer possible to change it by fixing on or other bug:  the problem is the corporate structure and governance and it will be very hard to convince people that anything substantive  has changed (in fact it's unlikely that it will).  
The result is that advanced users and managers abandon and shun the products: many people have been ripping Chrome out of corporate configurations for several years.  

See, for example, my comment from 15 months ago:  

I realise this is not a problem that _you_ can address personally, but somebody needs to take it in hand and it seems fairly clear that Google is failing to do so across the board.  

Let's keep commentary focused on technical details please.
Fine, agreed.  I'm simply pointing out that I (and many others) have explicitly cited the handling of *this* issue and others like it as the reason to strip Chrome out of massive numbers of corporate installations.  I fully appreciate that you may not find that information useful or actionable ... but that's rather the point, isn't it?  

That sounds like a great plan asanka@! Looking forward to the progress. :)
Project Member Comment 138 by, Jun 29 2016
The following revision refers to this bug:

commit b5fb4b4394a9c60ee711ee9f434072a7e7aee513
Author: asanka <>
Date: Wed Jun 29 11:06:08 2016

[net/cache] Skip the cache if the response is expected to exceed 2GB.

The state machine in http_cache_transaction doesn't handle partial
requests that are larger than numeric_limits<int32_t>::max(). If there
is a truncated partial cache entry for a large response, then the cache
will try to issue partial requests of size at most
numeric_limits<int32_t>::max() bytes until the entire resource is

However, if StopCaching() is called, as it often is for response of this
size that are downloaded, then the cache transaction switches to pass
through mode. This trips a bug in the state machine where the response
would be considered complete once the current partial request completes.

There are multiple issues in the cache transaction that needs
addressing, but for now we are going to skip the cache entirely if we
are likely to hit this case. The partial cache entry is most likely the
result of a MIME sniffing attempt and would be insignificant compared to
the resource size. Hence skipping the cache in this case isn't expected
to regress on performance.

This change adds several unit tests that drive a request with a response
size of 5GB. These tests are expected to be slower than the average net
unit test, but shouldn't cause trouble for the bots.

BUG= 89567 

Cr-Commit-Position: refs/heads/master@{#402774}


Status: Fixed
Marking as fixed even though there is more work to be done to resolve some of the underlying issues.
Is it fixed or fudged?
Sorry chaps I can't remember how to start another thread but I have another
Scrambled Bookmarks after re-start!
#141 - Should be, click the New Issue button.
Comment 143 by, Sep 11 2016
I see this is marked fixed a few months ago but I'm experiencing this issue right now. I have a file that is stopping download and showing as successful at 2,147,497,988 bytes, every single time. I've tried two drives including the system drive. (Both NTFS, on Windows 10, Chrome 52.0.2743.116 m)
> I see this is marked fixed a few months ago but I'm experiencing this issue right now.

That's how Google deals with bugs they can't fix:

They mark them as either Fixed, Won't Fix or Needs Information.

You'll have to open a new bug because now that this one is closed they will ignore it.

They'll probably close that one too.
Labels: M-53
The fix is rolling out to Chrome 53.
Comment 146 by, Sep 12 2016
Appreciate the update :)
> The fix is rolling out to Chrome 53.

The only bug this one is linked to is an aggregate of related bugs and that aggregate is marked "won't fix."

There is no mention anywhere in this bug report, comments or otherwise, of an intent to fix.

Is there any evidence that this bug will be fixed in Chrome 53?

Also, unless a bug is FIXED it shouldn't be marked fixed. It should be marked In Progress.
I'm using Chrome 53 on my MacOS, Sierra GM.
Does this mean that I can RELIABLY download 2+GB files?

Oh as it's marked "Fixed" I can nolonger add a comment!!!!
Sign in to add a comment