O Remote Desktop manipula arquivos ao copiar

3

Eu tenho uma caixa do Windows Vista Business no trabalho e uma caixa do Windows XP Professional em casa. Ambos são atualizados até os dentes, mas o problema ainda permanece. Os sintomas são:

  • Isso acontece quando eu conecto do XP à caixa do Vista;
  • copio um arquivo da caixa Vista para a caixa XP;
  • Isso acontece apenas quando copio o arquivo pelo Windows Explorer. Se eu uso o Far Manager, mesmo com "Use system copy routine" desativado, isso não acontece;
  • O arquivo recebe alguns bytes indesejados ao final. Arquivos PHP parecem obter bytes nulos (zeros); arquivos binários acabam de receber lixo.
  • Quanto maior o arquivo, mais bytes são acrescentados (e não parece ter corresposta a qualquer tamanho de bloco nos discos rígidos ou qualquer outra coisa)

Por exemplo, acabei de copiar um arquivo MP3. O tamanho na caixa Vista é 66 373 042 bytes, mas quando copiado na caixa XP é 66 387 968 bytes.

Não consegui encontrar nada desse tipo remotamente no Google. Alguma idéia?

    
por Vilx- 14.06.2009 / 23:55

8 respostas

3

Parece muito com esse problema que encontrei no microsoft.com: Determinados arquivos são corrompidos após serem copiados com o RDC no Windows Terminal Services

Como a Visa e o 2008 compartilham uma base comum, é muito provável que o mesmo bug afete os dois.

Uma coisa que eu gostaria de salientar é que usar tamanhos de arquivo para ver se um arquivo é OK não é uma boa solução. Eu uso hashes md5 ou sha para cada transferência WAN. Eu uso a ferramenta de código aberto md5deep para gerar e verificar os hashes. Existem muitas outras ferramentas de hash por aí, se você não gosta do md5deep.

    
por 26.06.2009 / 22:53
1

Eu tenho exatamente os mesmos problemas ao copiar arquivos para (ou de) um host de 64 bits do Windows 7 (RTM) e um cliente de 32 bits do Windows XP. Os tamanhos de arquivos de alguns arquivos copiados são maiores do que deveriam, fornecendo um hash CRC e MD5 diferente.

Eu fiz uma comparação de um arquivo copiado e original usando um editor hexadecimal que confirmou que o conteúdo é idêntico, exceto os bytes extras aleatórios acrescentados no final da versão copiada. Quando trunquei o arquivo para remover os bytes extras, os dois arquivos deram o mesmo hash MD5.

Não tenho a menor ideia do que está causando esse problema, pois o experimentei em vários sistemas e ambientes diferentes com várias configurações de firewall / rede. No entanto, espero que isso ajude alguém a identificar uma possível causa.

Ash

    
por 16.09.2009 / 11:36
0

Eu não sei qual é o problema, mas uma dica é que 66387968 é 66373042 arredondado para o 32768 mais próximo. Tem certeza de que obtém mais bytes quanto maior o arquivo?

    
por 15.06.2009 / 00:46
0

Você está vendo o tamanho no disco ou o atributo Tamanho? O tamanho no disco pode ser muito diferente, pois um cluster parcialmente usado será registrado como um cluster totalmente usado no campo 'tamanho no disco' (fazendo com que o tamanho do arquivo pareça maior, pois os clusters só podem ser usados para armazenar parte de um arquivo ).

Como você está lendo esses personagens extras 'lixo'? Porque se você estivesse inspecionando os clusters diretamente (usando um editor HEX com a capacidade de abrir o disco diretamente, em vez do arquivo), eles poderiam ser deixados de arquivos anteriores que ocupavam o espaço em disco físico ...

    
por 15.06.2009 / 01:13
0

Eu suspeitaria de algum tipo de problema entre as duas máquinas - qual é a segurança da sua infraestrutura de rede? Você pode testar isso criptografando conexões de cada máquina para a rede?

    
por 15.06.2009 / 16:43
0

Ambas as máquinas são 32 ou 64 bits? Eu poderia ver isso, talvez, ser um problema se um é de 64 bits e o outro é de 32 bits.

    
por 26.06.2009 / 22:15
0

Eu tenho tido esse problema também, e embora eu não tenha sido capaz de determinar por que isso acontece ou como corrigi-lo, eu encontrei uma solução alternativa.

Na máquina remota, você pode acessar a máquina local no Windows Explorer usando o alias da máquina "\ tsclient", portanto, para abrir sua pasta local C: \ Temp, vá para \ tsclient \ c \ temp na máquina remota. Copiar de e para a máquina local usando esse método não parece corromper os arquivos.

Isso requer que você disponibilize suas unidades locais para a máquina remota antes de se conectar.

(Eu suponho que o problema esteja relacionado à área de transferência sendo compartilhada entre as máquinas, enquanto que copiar dessa maneira usa a própria área de transferência da máquina remota.)

-Frodo

    
por 03.02.2010 / 10:01
0

A Microsoft oferece um hotfix que corrige esse bug:

link

    
por 02.12.2013 / 20:42