Files downloaded either by ftp or http are truncated at about 18.4 Mb when written to disk if a link is clicked on and 'Save this file to Disk' is selected from the downloading dialogue. The files appear to download normally but the temporary file in /tmp stops growing when it reaches a size of just over 18 Mb. When the download completes, this truncated temporary file is then moved to the place in the file system specified by the user. This does not occur if the link is clicked while the shift key is depressed to directly specify that the file is to be saved. This does not appear to be a network problem since in the case of http the fullsized file can be found in the cache after the download has completed. This behaviour has been present for a very long time but interestingly changed slightly in the few last weeks before reverting to previous form in 2001110610. In a nightly build downloaded last week (late October) files were truncated at 15.2 Mb rather than 18.4 Mb. Note the exact size varies by a few thousand bytes apparently at random. Example truncated sizes are 19333120 and 19332096 for the usual value and 15963136 and 15965184 for the smaller value last week. As of build 2001110610 file files are being truncated at 18.4 Mb again. This behaviour does not appear to be website dependent or affected by the files used (other than they must be larger than the truncation value). I would hypothesise that this problem is related to the speculative downloading which is started when the downloading dialogue is displayed but is not attempted if the link is shift-clicked (in which case the download does not appear to start until after the filename to save to has been selected). This inconsistant behaviour might also be considered a bug in itself (?).

Sorry. Did some more digging and it just /tmp filling up causing the problem. Ideally I suppose at the point where the user selects the filename to save to, the file should be moved out /tmp to that position in the file system (where there will hopefully be space for it) rather than waiting until the full download has completed and possibly filling /tmp. However this is probably not particularly trivial to implement.

prolly a dup of bug 65770... *** This bug has been marked as a duplicate of 65770 ***

mass verification of duplicate bugs: to find all bugspam pertaining to this, set your search string to "DuplicateBugsBelongInZahadum". if you think this particular bug is *not* a duplicate, please provide a compelling reason, as well as check a recent *trunk* build (on the appropriate platform[s]), before reopening.