I have a Windows Vista Business box at work and Windows XP Professional box at home. Both are updated to the teeth, but the problem still remains. The symptoms are:
- This happens when I connect from XP to Vista box;
- I copy a file from the Vista box to the XP box;
- This happens only when I copy the file via Windows Explorer. If I use Far Manager, even with "Use system copy routine" turned off, this does not happen;
- The file gets a few random junk bytes appended at the end. PHP files seem to get NULL bytes (zeroes); binary files just get junk.
- The larger the file, the more bytes get appended (and it doesn't seem to corresspond to any block sizes on the hard drives or anything)
For example, I just copied a MP3 file. The size on the Vista box is 66 373 042 bytes, but when copied on the XP box it is 66 387 968 bytes.
I have not been able to find anything remotely like this on Google. Any ideas?
Sounds awfully like this problem I found on microsoft.com: Certain files gets corrupted after being copied with RDC in Windows Terminal Services
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.
Ash
I don't know what the problem is, but one hint is that 66387968 is 66373042 rounded up to the nearest 32768. Are you sure you get more bytes the larger the file?
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?
Are both the machines 32bit or 64bit? I could see this, maybe, being a problem if one is 64 bit and the other is 32bit.
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.)
-Frode
Microsoft offers a hotfix that fixes this bug:
http://support.microsoft.com/kb/972828