Firefox downloads always corrupt

Discussion in 'General Software and Applications' started by sdamaged99, Jan 25, 2011.

  1. ramon zarat

    ramon zarat New Member

    Messages:
    7
    Likes Received:
    0
    GPU:
    HD3000 1.8Ghz
    SEEM TO HAVE FOUND THE SOLUTION! Read:

    @ Pill Monster: I was searching Google for this problem and found this thread. I don't care you think it's too old, the fact is it is till relevant to my issue. And no, it's not my RAM. My RAM pass 100% with MEMTest86 for 24H. Beside, it would have produce error in Prime95 or Intel Burn test...

    After writing this post, I've pushed my investigation further. Some other mention a possible correlation between the issue and Samba share or some other OS network related incompatibility. There was also some mention of Firefox integrated anti-virus scanning.

    I first disabled Firefox anti virus scanning by typing "about:config" in the Firefox address bar, then search for:

    "browser.download.manager.scanWhenDone"
    And
    "services.sync.prefs.sync.browser.download.manager.scanWhenDone"

    I set them both to "false"

    I went back to Firefox option to take another look around, just in case. In the advanced section, under the Network tab, there is a connection setting to tell Firefox "how to connect to he Internet". I changed the setting from no proxy to auto-detect proxy, closed Waterfox, restarted it and went to Filehippo to get some download action going.

    To my complement amazement, I clicked on the download of Firefox 16.0 beta 2 link, pressed "save file" and left the following file requester open for over 2 minutes before I finally pressed "save" and then, miracle, the file was not corrupted. Tried with 2 other file, and still OK.

    I hope this is not a fluke and that my issue is FINALLY resolved for good! I,ll need further testing to find if it was the proxy of the anti-virus scanning. :)
     
    Last edited: Sep 9, 2012
  2. ramon zarat

    ramon zarat New Member

    Messages:
    7
    Likes Received:
    0
    GPU:
    HD3000 1.8Ghz
    Ok, I have new development, and this time I'm able to replicate the problem AND eliminate it at will.

    First, it turn out the proxy and the virus scan had nothing to do with the issue. The test I've made previously involved a file type not configured with the same download condition (action) affected by the issue, namely .exe file.

    As you all know, Firefox can be configured to behave in a specific way (action) with each file type of you download, except .exe, which will always ask you what you want to do with it (that's why my previous test didn't show any error). This is configured in "option / applications" where you associate and "action" with each file type.

    All my archives file type (zip, 7z, rar) are setup to "save file". This is where the bug of Firefox is. To find this, I've opened the temporary folder of Firefox to take a look at the ".part" file Firefox generates (temporary download file). It turn out that when your action is set to "save file", the part file stays at zero byte, even If you leave your file requester open for a long time. Then, when you finally hit "save", the part file is transfered, still at zero byte, to its destination folder (the folder you choose to save your file to) where the downland is started and completed. Unless you hit "save" within 2-3 second, your file will be truncated, meaning a smaller size than it should be, and therefor, corrupted.

    Compare this behavior to this:

    Next, I've changed the action for my zip file to "always ask", tried to download the same zip file. Firefox opened a requester asking me what I want to do. Amazingly, at this very instant, I could see the part file being created in the temps folder and growing in size byte by byte as the download proceeded until the file reach the actual correct size. I then choose "save file" and then "save". This time, it's the completed download part file that was transfered to the destination folder, so it obviously didn't care how much time I took to press "save", the file was 100% OK as it was already entirely downloaded in the temp folder.

    In resume:

    Action "save file": Keep the part file in the Firefox temp folder at zero byte, until you hit "save". Then the part file, still at zero byte, is transfered as is to the destination folder where the actual download occurs. If you take too much time to hit "save", your file will be truncated, especially with small size file (larger file size tolerate longer time to hit "save"). Try it with a zip file of around 1500Kb to replicate the problem. Click on that file link, then wait 15 seconds to hit "save". Test the archive integrity = fail...

    Action "always ask": As soon as you click on that same zip link, the part file start to download straight into Firefox temp folder. You then select "save file' and click OK. Then you choose your destination folder and click "save". Either the partially downloaded part file is transfered to the destination folder where the download is completed, or if you took too long to hit "save", it's the completed downloaded file that is transfered to the destination folder. No matter how long I've waited, the final zip file always check out as valid. No mater what I've tried, I couldn't procedure a corrupted file.

    In conclusion, if you want to avoid corrupted download files with Firefox, make sure to set their corresponding "action" to "always ask". That is unless you always download you stuff to the same folder and hit "save" very quickly, then, of course, you were never even aware of this issue. My problem is I never download to the same folder and searching around my multi-terabyte NAS to find the appropriate destination folder pretty much always take too much time for Firefox taste and always lead to corrupted file when the "action' is set to "save file". That mean now I use the action "always ask" for all my file to be downloaded and have to live with an extra step to initiate each download.

    NOTE: I would appropriate very much if anyone could try to replicate the problem and confirm it. I successfully replicated it myself on 2 different PC. 1 with XP 32bit SP3 and Firefox 14.1. The other with Win7 ultimate 64 and WaterFox 15.0.

    I hope it will help those who were searching for an answer to this problem. Regards,

    Ramon
     

Share This Page