HTTP Download stops at 2GB when saving the file on another NTFS drive

Apr 09, 2014

이슈 내용들..

Chrome Version       : 16.0.912.77 (Mac Mountain Lion)
URLs (if applicable) : various
Other browsers tested: Non

What steps will reproduce the problem?
1. try to download a file greater than 2.15GB
2. Chrome Downloads show the expected size as 2.5, 2.6, 3.2 etc.

What is the expected result?
The download is shown as complete.

What happens instead?
The download is shown in Finder as just 2.15 EVERY time I try to download bigger file.
When playing the mpg4 file the video and sound stop but the tile code keeps running and there is NOTHING I can do to see or hear the missing last section.

This bug was reported on Jul 17, 2011 and is not fixed yet... How is that possible? :-(
=> 재현은 Windows OS/Linux/Mac OS X 모두 발생함 
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?
#62 asanka@chromium.org
#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 https://code.google.com/p/chromium/codesearch#chromium/src/net/http/partial_data.cc&l=472)
- 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.
#63 asanka@chromium.org
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

덤프된 데이타 분석해보기

#61: Thanks for the log! That was very helpful.

=> #61 커멘트 데이타


  • Windows 7 + NTFS
  • 4G data.avi 다운로드시 2G 에서 정지됨.
  • ( 크롬의 다운로드 매니저 화면 띄우지 않아야함 )

Reference :