A download can get interrupted for several reasons. When a weak signal WiFi connection cause downloads to be harder to fully get downloaded, the Downloads window often says "X.x MB download complete" (where X.x are the figure for the file size) when in fact only part of the file has been downloaded in certain conditions, typically on weak WiFi connections and especially when trying to download just too many files at ones.
All downloads starts with a file size figure printed out such as "y kB of X.x MB" and a download speed printed where y and the speed figures are continuously updated. The only figure here that is not and should not be updated is the file size X.x since it is a constant number. In the end only downloaded files (files on your local host typically, downloaded from the internet) which ends up being of the exact same size as was stated as being the initial file size should be defined as 'complete' and no matter the cause of an abrupt download, the abrupt downloaded files should never be defined nor be referred to as being complete (in the downloads context) because they aren't. The Download windows also get things right and can spot when a download gets only partial and halted to early.
To reproduce: best way would be to be seated with a very weak WiFi spot. Then try to download several (many) files so that the actual weak spot were failure is caused is the WiFi connection and no were else. Be sure of the sizes the files has and compare to your 'completed files'. If you manage to get the downloads be interrupted by the very weak WiFi connection you have set up you should see 'completed' files that are much smaller in size than the original files are. They differ from what the Downloads windows says early on when the download attempt starts.
Suggestion: if the early file size figure and the actual size downloaded differ, the downloaded file should be defined as not being complete. That will demand that the early file size figure are trustworthy? If it is not trustworthy then the obvious would be to fix that part first and if that is impossible you would have to use whatever method you do when Downloads window gets it right. Probably not a file size comparison as I suggested since that would probably be inherited by the bug:ed part this report is lining out for you and not become bug:ed in the first place?
If anything is unclear, just ask and I do my best to clarify.
All downloads starts with a file size figure printed out such as "y kB of X.x MB" and a download speed printed where y and the speed figures are continuously updated. The only figure here that is not and should not be updated is the file size X.x since it is a constant number. In the end only downloaded files (files on your local host typically, downloaded from the internet) which ends up being of the exact same size as was stated as being the initial file size should be defined as 'complete' and no matter the cause of an abrupt download, the abrupt downloaded files should never be defined nor be referred to as being complete (in the downloads context) because they aren't. The Download windows also get things right and can spot when a download gets only partial and halted to early.
To reproduce: best way would be to be seated with a very weak WiFi spot. Then try to download several (many) files so that the actual weak spot were failure is caused is the WiFi connection and no were else. Be sure of the sizes the files has and compare to your 'completed files'. If you manage to get the downloads be interrupted by the very weak WiFi connection you have set up you should see 'completed' files that are much smaller in size than the original files are. They differ from what the Downloads windows says early on when the download attempt starts.
Suggestion: if the early file size figure and the actual size downloaded differ, the downloaded file should be defined as not being complete. That will demand that the early file size figure are trustworthy? If it is not trustworthy then the obvious would be to fix that part first and if that is impossible you would have to use whatever method you do when Downloads window gets it right. Probably not a file size comparison as I suggested since that would probably be inherited by the bug:ed part this report is lining out for you and not become bug:ed in the first place?
If anything is unclear, just ask and I do my best to clarify.
Linear Mode
