8 Answers
8

Since Visa and 2008 share a common base it's highly likely the same bug afflicts them both.

One thing I'd point out is that using file sizes to see if a file is OK is not a good solution. I use md5 or sha hashes for every WAN transfer. I use the open source tool md5deep to generate and check the hashes. There are plenty of other hash tools out there if you don't like md5deep for some reason.

I have exactly the same problems copying files to (or from) a Windows 7 (RTM) 64-Bit Host and a Windows XP 32-Bit Client. File sizes of some copied files are larger than they should be, giving a different CRC and MD5 hash.

I have done a comparison of a copied and original file using a hex editor which confirmed that the contents are identical except for the extra random bytes appended on the end of the copied version. When I truncated the file to remove the extra bytes, the two files then gave the same MD5 hash.

I have no idea what is causing this problem as I have experienced it on a number of different systems and environments with varying firewall/networking configurations. However I hope that this may help someone else identify a possible cause.

Are you looking at the Size on Disk, or the Size attribute? Size on Disk can differ greatly, because a partially-used cluster will register as a fully-used cluster in the 'size on disk' field (thus making the file size appear larger, as clusters can only be used to store part of one file).

How are you reading those extra 'junk' characters? Because if you were inspecting the clusters directly (using a HEX editor with the ability to open the disk directly, rather than the file), they could be left over from previous files that occupied the physical disk space...

I would suspect some sort of problem between the two machines - how secure is your network infrastructure? You might be able to test this out by encrypting connections from each machine to the network?

It's the public internet. Read the question - one box is at my workplace, the other is at my home. And doesn't RDP encrypt stuff anyway? Besides - the problem isn't new. It's been like that for more than half a year. I don't think anyone's hacking there. :P
–
Vilx-Jun 18 '09 at 8:34

I've been having this problem too, and though I havent been able to determine why it happens or how to fix it, I have found a work-around.

On the remote machine you can access the local machine in windows explorer by using the machine alias "\tsclient", so to open your local C:\Temp folder, go to \tsclient\c\temp on the remote machine. Copying to and from the local machine using this method does not seem to corrupt the files.

This requires that you make your local drives available to the remote machine before you connect.

(I assume the problem is related to the clipboard being shared between the machines, while copying this way uses the remote machine's own clipboard.)