Hello vsiIT, seek in you extensions if you have an extension to manage your downloads then disable the extension, and check it again.

You can also try to delete the compreg.dat file from profile folder, before do that close firefox from Quit option.

thank you

Hello ideato,

I have no extensions, I've tried with a fresh installation as well (so with a fresh profile) and it's still not working.

thanks

Please try another download folder, and check also if your antivirus software (including firewall, antispyware etc) block the access to the files in that specific download folder.

thanks

I tried to change the download folder, no help tehre. I also tried disabling the Antivirus and Firewall, still the same. I even tried to boot windows in safe mode, and when I download the file I don't get the error but the file just fails to download.

I just want to underline that if I downgrade to version 32 everything works.

thanks

Yes, probably it is your security software that cause the issue, try to remove all rules for Firefox from the permissions list in your firewall. In windows safe mode with network support firewall and antivirus is totally disable.

thanks

If you empty the Temp folder, does that make any difference?

If you check the folder at the time this message appears, is Firefox stranding a .part file in the folder, or it is getting properly renamed to the real download name, or is it vanishing, or is it never created in the first place?

Do you know whether the affect users are using the Temp folder to launch the file directly in an external viewer, or if Firefox is using it as a temporary waystation for a file being saved to the Downloads folder or another location?

Upon further research:

This is an old error message relating to corrupted downloads (http://kb.mozillazine.org/Source_file_could_not_be_read), but has become more prevalent in Firefox 33.

To make a long story short... before, if the server sent a response that was smaller than the stated size, the discrepancy was ignored and the download was treated as okay. Starting in Firefox 33, a file smaller than the stated size is treated as corrupted.

This comment in the bug tracking system has more information: https://bugzilla.mozilla.org/show_bug.cgi?id=1083090#c8

Along the lines of the last post, what happens if you stop Firefox from telling the web server that you will accept compressed files? Here's how:

(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.

(2) In the search box above the list, type or paste enco and pause while the list is filtered

(3) Double-click the network.http.accept-encoding preference and

(A) If it has the default value (line is not bolded), delete all of the text and click OK.

(B) If it has a customized value, copy the current value to a safe place for potential later use, then delete all of the text and click OK.

When you visit the site again, Firefox should omit the usual headers saying that it accepted gzip/deflate encoded responses. Any difference?

Hi jscher2000, Brilliant, that solved the problem! I knew that there might have been something wrong with the way the PDF was created, but I wasn't aware of this layer of extra security. Well, now I have to change all the settings for all of the Firefox in the company, it's going to be a fun weekend. Thanks!

If you run SugarSync locally, you might be able to upgrade your web server to one that computes the file size AFTER compressing it, or disable compression.

If you use a SAAS solution for SugarSync, you might complain to your vendor, as this is likely to affect many of their customers.

We run it locally, I tried to disable compression on the generated file but it doesn't seem to work, but maybe I need to look a bit more into it 'cause I haven't had enough time. Anyway thanks to your very good debugging skills!