User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) I have two windows 7 RTM computers and they both experience the same thing. One is x86 and the other is x64. I am running 3.5.2 in x64 and 3.0.13 on the x86 machine. Downloading files from firefox to shares on the other windows 7 machine results in short files. If I download a 8MB file 10 times, the filesize is different every time, sometime the whole file will complete. Using IE this works every time. Writing to a linux or xp or 2008 share works everytime. If I look in the mozilla cache directory under my user profile I can see the downloaded files listed by some hash name. There is a file for every time I tried to download it. All the cache files are the same size and are the full file length. If I rename one to the actual filename it works fine. Another side note is that if you watch the .part file as the download progresses, the file never grows on the windows share. It gets created with some arbitray size, but then never increments like it does on the other shares. Network user has full access to both the files system and the network share. Reproducible: Always Steps to Reproduce: 1.create remote windows 7 share and map network drive on local machine 2.set local firefox to same to mapped network drive 3.download some files Actual Results: downloaded files are corrupt because file length is short. Expected Results: I expect to be able to use the downloads.

To clarify the IE works everytime comment above means if I use IE the downloaded file is good everytime. Same for the other I did try disabling browser.download.manager.scanWhenDone which made no difference.

I just found that if I set download manager to go to the unc and not the mapped drive letter, the downloads complete fine. So set download manager to download to this and it works \\server\share map a drive letter to the same path and set download manager to use that drive and it fails 95% of the time.

One last note, mapping the share on the same computer works fine. The problem is only downloading to a drive letter mapped to a remote windows 7 share. So if I map y: to \\computer1\share on computer1 it works fine, y must be mapped to computer2. I also went and tested from a win2008 server machine and a xp box to the same windows 7 share and it works fine. The problem appears when firefow is running on a windows 7 machine writing files to a windows 7 mapped share.

If you download files from a Windows 7 Client to a remote Share the file is store corrupt. If you download it local no problem. The Problem is not only if you store files to a remote Windows 7 Share it's also to a Win2008/R2 share.

I can confirm this problem in Firefox (3.5.6 and 3.5.7) with Windows 7 and I have discovered how the problem occurs but I have no idea to fix it. I can also confirm that fizbin is correct in the fact that this issue only occurs when you download to a mapped drive. If you download directly to the share using a UNC path the download succeeds. The problem has something to do with SMB v2 on Windows 7. SMB v2 was added to Windows Vista/Server 2008/7 and is used as the default application-layer networking protocol between those systems. I recently upgraded my home PC to Windows 7 and had no trouble downloading files directly from Firefox to the existing Windows Server 2003 R2 Standard x64 server I was running, most likely because Windows Server 2003 uses SMB v1 for communication. I use mapped drives to access the shares on my server. After completing my Windows 7 upgrade I upgraded my server to Windows Server 2008 R2 Standard and shortly thereafter I noticed that files I downloaded from my Windows 7 PC directly to the server using Firefox would be corrupted. Upon investigation I discovered that even though Firefox was telling me the download completed the file size on the server would be too small (ex 30-50KB missing out of 100MB), as if not all of the data successfully transferred. After a lot of hours of testing I discovered that if you force either the client or server to use SMB v1 instead of SMB v2 the problem would immediately cease. I had a Windows Vista PC that I was also testing with and even when using SMB v2 Firefox would not corrupt the download when downloading directly to the server. This issue only occurs with Windows 7 clients. Steps to reproduce: 1. Using a Windows 7 PC, download a file directly to a Windows 7/Server 2008 mapped drive using SMB v2 (the default protocol). 2. Firefox reports the download completes but when you try to use the file it is corrupt. Larger downloads (100MB+) will corrupt every time, smaller downloads have a chance of corrupting. Downloading the file to your local PC is always successful, and upon further investigation the file on the server (corrupt) is always smaller than the file on the local PC (intact). Workarounds: Option 1: Disable SMB v2 on the Windows 7 client or on the destination server/client. Option 2: Download using UNC path rather than a mapped drive. I hope this can be picked up by someone and fixed quickly, as I noticed that the original bug was opened 4.5 months ago. It has the potential to become a serious problem as companies using Windows Server 2008 upgrade to Windows 7, as many of them use mapped drives. I can perform any further testing that is needed.

I wanted to update my previous post. I did some more testing and it appears that using the UNC path isn't a valid workaround. Firefox has corrupted several files using UNC instead of the mapped drive. The only successful workaround for this issue is Option 1, which is to disable SMB v2 on the Windows 7 client or on the destination server/client.

marking new based on dupe, could be still a bug in the AV software that is started to scan downloaded files or a win7 bug

I do not use active AV software so that can be ruled out. As for a Windows 7 bug, it is possible but right now only Firefox is affected. If you use IE to download the file it downloads just fine. Has anyone tested Firefox 3.6? I haven't upgraded yet due to the fact that IE Tab is not compatible. As soon as I am able to upgrade, I will test if no one has tried by then.

Not a workaround that is available to everyone, but one that suggests SMBv2 is to blame. Using a local linux machine to mount the same network share, I then installed samba and shared the mounted share. Thus meaning that Firefox alone saves files via the linux box and SMBv1 whilst I don't need to make a sweeping change to the client/server by disabling SMBv2. I just did my usual test downloading 30 files via easynews which has *always* resulted in corrupt files in at least 50% of the downloads and I got fully successful results.

I've tested downloading files to network drives with the AV off, Firefox 3.6 and I still get the issue.

@Steve Allison - Thanks for the SMB v2 confirmation. As I said before, this issue only happens with Windows 7 using SMB v2, but doesn't affect Windows Vista using SMB v2. Microsoft must have made some sort of change(s) that Firefox doesn't agree with. @Greg - Thanks for testing Firefox 3.6 and confirming that this issue still exists in that version.

duplicate bug with some info: https://bugzilla.mozilla.org/show_bug.cgi?id=545650

Can the Product please be changed to Firefox? It is erroneously set as Toolkit. @peterdk - Thanks for the info. I made a post in that discussion directing to this bug to hopefully get more people to vote for it. This is a serious issue!

@Tyler: Isn't toolkit the parent of component Download Manager? Looks like it is correct this way

I have submitted a patch for this bug at the URL below. I would be greatfull if someone could test this on their machine. https://bugzilla.mozilla.org/show_bug.cgi?id=545650 Thanks, Steve