É possível, pelo menos, para o FAT32, no entanto, não lembro o nome da ferramenta.
Se bem me lembro, o certo é baseado em uma primeira chamada para um furo de comprimento total e atribuí-lo ao novo fluxo, então o arquivo é lido e escrito nesse fluxo.
Também é possível com o NTFS através da cópia de pré-alocação, se bem me lembro.
Mas, para arquivos compactados NTFS, não há como ... já que o Windows primeiro escreve o arquivo (não-compactado) e depois ele compacta o arquivo em partes ... para dizer a verdade, ele faz isso em um pipeline. .. essa é a razão pela qual o arquivo fica tão fragmentado (um arquivo de 10GiB pode criar mais de cem mil fragmentos).
Eu não conheço nenhuma ferramenta / comando capaz de evitar isso quando a compactação NTFS está habilitada. Eu usei uma ferramenta há muito tempo que tinha uma boa GUI para copiar sem causar fragmentação no Windows, mas não consigo lembrar o nome.
Portanto, o melhor que posso dizer é usar no windows o utilitário de linha de comando XCOPY com o /J flag.
Ele tenta não fragmentar, ideal para arquivos grandes se a compactação NTFS estiver desativada ou se você estiver usando o FAT32.
Explicação da fragmentação do pipeline de compactação NTFS:
- O bloco N será escrito no Cluster N
- Clusters espalhados N + # serão compactados e armazenados em algum outro lugar, então os clusters entre N e N + # serão livres, também conhecidos como arquivos, serão fragmentados, muito fragmentados. 10GiB = 100000 fragmentos, assumindo uma compressão de 50%, é por isso que a compactação NTFS é muito ruim. Se o arquivo for compactado primeiro na RAM e depois enviado para o disco, nenhuma fragmentação ocorrerá ou, pelo menos, poderá ser evitada.
Outro efeito colateral desta maneira de fazer as coisas é assumir que temos 5Gib de espaço livre e eu quero escrever um arquivo de 6GiB que após a compactação levará apenas 3GiB. Isso não é possível, mas se você primeiro mover um 2GiB (não compressível) para outro local, o espaço livre será 7GiB, 6GiB, a compactação fará com que seja apenas 3GiB, o espaço livre será 4GiB, e depois o 2GiB do original os dados que nós movemos e voila tudo está lá e 2GiB livre. Aponte-se que, se não houver espaço suficiente para o arquivo descompactado, não será possível ser copiado em NTFS e não importa se, após a compactação NTFS, existir espaço suficiente. Precisa de tudo porque primeiro escreve sem compressão, então aplica a compressão. Por último, os drivers NTFS fazem isso no pipeline, portanto, em teoria, ainda seria possível, mas eles não alteraram a parte do tamanho livre de verificação.
O Windows não grava o arquivo "após" compactando, o Windows "compacta" o arquivo "após" salvando-o, então para cada cluster o disco verá duas tentativas de gravação, primeiro com dados não compactados, segundo com compactado dados. Os controladores NTFS de pipeline modernos evitam que o HDD veja as duas gravações, mas na primeira versão do NTFS, o HDD grava todo o arquivo descompactado e, em seguida, compacta o arquivo. Era muito perceptível com arquivos muito grandes e bem compactáveis. Escrever um arquivo de 10GiB que o NTFS compactou em apenas alguns MiB (um arquivo cheio de zeros) demorou mais para gravar do que gravar a versão não compactada do arquivo. Hoje em dia o pipeline quebrou isso, e agora demorou muito pouco tempo, mas o tamanho livre anterior ainda está lá.
Espero que um dia o método de compactação NTFS faça isso em uma linha, para que possamos obter arquivos compactados NTFS não fragmentados sem a necessidade de fragmentá-los depois de escrevê-los. Até lá, a melhor opção é XCOPY com o /J flag e CONTIG ou aquela ferramenta gráfica que não consigo lembrar o nome. Foi enquanto o Windows estava apenas no XP, e tinha opções para fazer uma pausa, para copiar em paralelo de HDD1 para HDD2 e HDD3 para HDD4, e é claro que o desejado, para pré-alocar. Espero que isso ajude!