Strange corrupção de poupança de Textpad 5 no Windows 7-64 VirtualBox VM para pasta compartilhada com o host Mac

Question

Eu tenho uma nova instalação do Windows-7 de 64 bits rodando no Virtual Box em um MacBook Pro. Eu estou usando o TextPad 5 dentro desse ambiente para editar arquivos de origem que vivem em uma pasta compartilhada que está no Mac Host. Quando salvo alguns desses arquivos de origem, o arquivo salvo termina com uma quantidade do final do arquivo repetida uma ou mais vezes. Por exemplo, um arquivo que tenha isso no final:

    ...
    return ttp;
    };

seria, uma vez salvo, aberto com:

   ...
   return ttp;
   };

};

É definitivamente um problema de como o arquivo é escrito ao contrário de como é lido, porque eu posso ver isso agora importa qual app eu uso para abrir o arquivo com (NotePad e Word em Windows 7, TextWrangler de volta ao Mac).

Eu tentei salvar como ANSI e UTF-8 e com ou sem a lista de verificação 'Escrever Unicode e UTF-8 BOM' marcada nas preferências do TextPad. Isso não acontece com todos os arquivos, embora eu não possa ver nenhum padrão sobre quais arquivos têm ou não o problema. Isso não acontece com arquivos gravados na unidade c: \ do Windows 7. E até agora isso não acontece de outros aplicativos salvando arquivos, apenas TextPad.

Alguma idéia?

Minhas versões:

• Textpad 5.4.2
• Windows 7 Professional de 64 bits, totalmente atualizado
• VirtualBox 4.0.8 r71778
• OSX 10.6.7

Answer 1

Isso realmente soa como um bug no TextPad - Eu não consigo pensar em nada que o VirtualBox estaria fazendo que faria com que ele se comportasse dessa maneira. A forma como as pastas compartilhadas funcionam, basicamente mapeia uma unidade de rede falsa para o seu convidado do Windows 7. Se foi o VirtualBox introduzindo o comportamento estranho, você deve ver isso manifestado em todos os outros aplicativos.

Eu tenho visto vários programas se comportarem mal ao salvar arquivos antes, principalmente em como basicamente sobrescrevem o conteúdo do arquivo existente sem realmente redefinir o comprimento do arquivo, ou zerar os bytes no final. O que isto significa é que se você "encurta" o seu arquivo removendo alguns caracteres ou linhas, você obtém o comportamento exato descrito acima. Você certamente poderia realizar alguns testes para realmente descobrir a origem do problema, e usar isso para fazer os autores corrigirem os erros:

• Você pode replicar o comportamento usando Salvar como, em vez de apenas Salvar?
• Você pode replicar o comportamento tornando o arquivo mais curto? mais tempo?
• Você pode replicar o comportamento em outras unidades de rede? ou apenas recursos de Pastas Compartilhadas?
• Algum outro "filtro" pode afetar a operação de salvamento, por exemplo, anti-vírus, etapas de pós-compilação, controle de origem, etc.

Como demonstração, usando o PowerShell - aqui está como você pode replicar o mesmo comportamento que está vendo. Comecei tomando o parágrafo de abertura de Um conto de duas cidades e salvando-o como tale.txt

$text = gc tale.txt
$fs = [System.IO.File]::OpenWrite("tale.txt")
$sw = New-Object System.IO.StreamWriter($fs)
$sw.Write($text.Replace("the",""))
$sw.Dispose()

Você pode ver que todas as 15 instâncias de "the" palavras foram substituídas pela string vazia como pretendido, com a conseqüência não intencional dos últimos 45 bytes do arquivo original restante, repetindo assim a frase " no grau de comparação superlativo apenas. "duas vezes no final do arquivo - semelhante à situação descrita acima.

Para completar, a solução simples para o exemplo de código incorreto acima é não usar o método OpenWrite e, em vez disso, chamar o método estático WriteAllText na classe File.