up vote 0 down vote favorite
1
share [g+] share [fb]

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?

link|improve this question
50% accept rate
Vilx, have you tried the remote printing or remote clipboard functionality? Do these have any issues? What antivirus are you running on each side? – Joel Mansford Jun 21 '09 at 22:51
feedback

7 Answers

up vote 2 down vote

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.

link|improve this answer
Sounds like it alright! – Vilx- Jun 27 '09 at 16:39
feedback
up vote 0 down vote

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?

link|improve this answer
feedback
up vote 0 down vote

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...

link|improve this answer
No, no, I'm looking at the "Size" attribute and at the file contents themselves. – Vilx- Jun 14 '09 at 23:32
I first noticed this when it started messing up my PHP files and the output to the browser was getting weird. :) – Vilx- Jun 14 '09 at 23:32
Hmm. Don't know then. Very odd! – Mark Henderson♦ Jun 15 '09 at 2:07
feedback
up vote 0 down vote

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?

link|improve this answer
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
feedback
up vote 0 down vote

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.

link|improve this answer
No, both are 32-bit. – Vilx- Jun 27 '09 at 16:37
feedback
up vote 0 down vote

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

link|improve this answer
feedback
up vote 0 down vote

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

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.