Início / unix / Perguntas / 676202
Accepted
FlashDaggerX
Asked: 2021-11-05 11:28:46 +0800 CST

Dividir um arquivo pequeno em segmentos de 512 bytes o altera, mas dividi-lo em segmentos de 1k não

  • 772

Então, estou tentando dividir um arquivo de 64 MB FileCarve.001em segmentos de 512 bytes (cada bloco tem 512 bytes). Eu preciso ter certeza de que o arquivo tem os mesmos dados quando dividido em arquivos menores, então eu cattodos os arquivos para padronizar e canalizá-los sha256sum(há muitos arquivos, então eu preciso fazer isso com finde xargs).

Dividir o arquivo em segmentos de 512 bytes parece distorcer os dados quando a saída é dividida pelo splitcomando.

$ dd if=FileCarve.001 bs=512 | split -b512 - splits/img
131072+0 records in
131072+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 4.10824 s, 16.3 MB/s
$ sha256sum FileCarve.001 
3e64100044099b10060f5ca3194d4d60414941c7cb26437330aba532852a60cd  FileCarve.001
$ find splits/ -type f -print0 | xargs -0 cat | sha256sum
25b37f28204895e5d0b1cb160c5fa599d15188baf7e529ccc92a10fdb3f0515a  -

Mas dividir o arquivo em segmentos de 1 kilobyte (1000 bytes) parece funcionar bem.

$ dd if=FileCarve.001 bs=512 | split -b1k - splits/img
131072+0 records in
131072+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 2.06029 s, 32.6 MB/s
$ sha256sum FileCarve.001 
3e64100044099b10060f5ca3194d4d60414941c7cb26437330aba532852a60cd  FileCarve.001
$ find splits/ -type f -print0 | xargs -0 cat | sha256sum
3e64100044099b10060f5ca3194d4d60414941c7cb26437330aba532852a60cd  -

Por que eles são diferentes? Há algo que não entendo sobre como os blocos funcionam em um dispositivo de armazenamento?

Em resposta a um comentário: limpei o split/diretório em cada execução.

find wildcards

1 respostas

  1. Best Answer

    A ordem findprocessa os arquivos não é determinística. Pode ser exatamente a mesma ordem que a chamada do sistema subjacente fornece, o que provavelmente depende da estrutura do sistema de arquivos subjacente e pode ser essencialmente aleatório. Algumas implementações podem processar a lista de alguma forma, mas não espere que ela seja classificada.

    Vamos tentar com um arquivo menor. cat frag*reproduz o arquivo correto, já que os globs do shell classificam os nomes dos arquivos:

    $ split -b512 orig.bin frag
$ cat frag* > new.bin
$ sha256sum orig.bin new.bin 
8d12b42623eeefee872f123bd0dc85d535b00df4d42e865f993c40f7bfc92b1e  orig.bin
8d12b42623eeefee872f123bd0dc85d535b00df4d42e865f993c40f7bfc92b1e  new.bin

    Mas findnão, então obtemos um arquivo diferente:

    $ find . -name 'frag*' -exec cat {} + > second.bin
$ sha256sum second.bin 
821325739ca65d1cb568ecf3a16bd2e01ac4eef1419b4d714834fab07d2f135c  second.bin

    Apenas correr findpara imprimir os nomes revela isso muito bem:

    $ find . -name 'frag*' |head -5
./fragzbgv
./fragzbmg
./fragvt
./fragyd
./fragzayc

    Isso foi no Linux e ext4. Eu acho que ele usa algum tipo de hash e árvores para armazenar os nomes dos arquivos, produzindo assim uma ordem de aparência aleatória. No tmpfs, obtive a lista na ordem de criação inversa , o que não é tão aleatório, mas ainda atrapalharia esse caso.

    Classificar explicitamente a lista de nomes de arquivos deve ajudar:

    $ find . -name 'frag*' -print0 | sort -z | xargs -0 cat > third.bin
$ sha256sum third.bin 
8d12b42623eeefee872f123bd0dc85d535b00df4d42e865f993c40f7bfc92b1e  third.bin

    O fato de ter funcionado para você com 1k blocos, provavelmente é um acidente ...

    Como um aparte, não sei por que você está usando dd bs=512para a entrada em vez de apenas catou fornecendo splito nome do arquivo diretamente. O que ddfaz é ler e escrever com um tamanho de bloco específico, mas o pipe entre dde sortnão conserva os tamanhos dos blocos, é apenas um fluxo de bytes, e o sistema de arquivos realmente não deve se importar com o tamanho do bloco que você usa para ler o arquivo, seja ele 512 (2^8) ou 521 (um primo) bytes.

    • 40

relate perguntas