Como criar um arquivo de tamanho exato

Windows

fsutil, e uma versão em PowerShell que não precisa de nada extra

O fsutil vem com o Windows. Ele recebe o tamanho em bytes, então calcule o número antes - 10 MB são 10485760, 100 MB são 104857600, 1 GB é 1073741824.

fsutil file createnew test10mb.bin 10485760

Medido no Windows 11: funciona em um prompt comum, sem precisar de um elevado, e o arquivo sai com exatamente 10485760 bytes.

O PowerShell faz o mesmo sem chamar outro programa, e entende unidades:

$file = New-Object System.IO.FileStream "test10mb.bin", Create, ReadWrite
$file.SetLength(10MB)
$file.Close()

10MB no PowerShell significa 10485760 bytes, a mesma contagem em base 1024 que o Explorer usa, então os dois comandos acima produzem o mesmo tamanho.

Linux

dd, truncate e fallocate, e a diferença que pega as pessoas

O dd é o que todo mundo conhece. Ele escreve os bytes de verdade:

dd if=/dev/zero of=test10mb.bin bs=1M count=10

O truncate é instantâneo, e essa é a pegadinha. Medido no Alpine Linux, o arquivo informa 10485760 bytes e ocupa zero blocos - é um arquivo esparso. Qualquer coisa que o leia recebe dez megabytes de zeros, mas o disco nunca cedeu o espaço:

truncate -s 10M test10mb.bin

Isso serve para testar um limite de upload e engana para testar uma cota de disco. O fallocate é o que se deve usar quando o espaço precisa ser real:

fallocate -l 10M test10mb.bin

E quando o conteúdo precisa ser incompressível, para que um compactador não consiga comprimi-lo de volta:

head -c 10485760 /dev/urandom > test10mb.bin

macOS

mkfile, que não é esparso, e os dois que você já conhece

O macOS traz o mkfile. Medido no macOS 26.6.2: 10485760 bytes e 20480 blocos, então o espaço é realmente alocado em vez de prometido:

mkfile 10m test10mb.bin

dd e truncate também estão lá e se comportam como no Linux:

dd if=/dev/zero of=test10mb.bin bs=1m count=10
truncate -s 10M test10mb.bin

Onde isso deixa de funcionar

Um arquivo do tamanho certo não é um arquivo do tipo certo

Tudo acima dá um bloco de zeros. Isso basta quando o que está sob teste olha só o tamanho - um limite de upload, uma cota, uma transferência. Deixa de bastar no momento em que qualquer coisa abre o arquivo.

Medido, e vale a pena fazer você mesmo: crie um arquivo de 2 MB com fsutil, chame-o de photo.png e entregue a uma biblioteca de imagens. O Pillow responde cannot identify image file. Não é um PNG. Nunca foi - só o nome dizia que era.

Isso importa mais do que parece, por causa de o jeito como o teste então falha. Seu endpoint de upload recusa o arquivo, seu teste fica verde e você conclui que o limite de tamanho funciona. Ele não recusou pelo tamanho. Recusou porque os bytes não eram uma imagem, e a regra que você queria testar nunca foi alcançada.

• um parser o recusa antes de qualquer regra de tamanho ser olhada
• uma etapa de miniatura falha e o erro que você lê é sobre a miniatura
• um antivírus ou uma verificação de conteúdo o recusa por um terceiro motivo
• um visualizador não mostra nada, e ninguém sabe dizer se esse é o bug

O outro caminho

Um arquivo real desse formato, exatamente no tamanho que você pediu

É isso que o Testing Files Generator faz. O arquivo é um genuíno do seu formato - abre no programa a que pertence - e tem o número exato de bytes que você pediu, ao byte:

tfg generate --format png --size 10mb --out ./fixtures

Peça um tamanho que um formato não alcança e você recebe um erro que nomeia o piso e o motivo, nunca um arquivo de tamanho errado. A página de formatos lista cada formato com o menor arquivo que ele pode produzir.

E um limite são três casos de teste em vez de um, então a ferramenta monta os três:

tfg generate --format pdf --boundary 10mb --out ./edges

Isso dá 10485759, 10485760 e 10485761 bytes, e um manifesto dizendo quais deles seu sistema deve aceitar e quais deve rejeitar. A página de casos de uso percorre isso e outras quatro tarefas para as quais foi feito.

Gratuito e de código aberto, GPL-3.0. Sem cadastro. Os downloads de Windows e macOS são assinados e iniciam sem aviso.

Então qual usar?

• Use o comando do sistema

  Quando nada abre o arquivo. Testar um limite de tamanho em um endpoint que checa o tamanho primeiro, uma transferência, uma cota, um disco cheio. É uma linha e já está instalado.

• Use um gerador de verdade

  Quando qualquer coisa interpreta, renderiza, importa ou extrai o arquivo - e quando você precisa das mesmas fixtures amanhã, em outra máquina, byte a byte.

Os dois estão nesta página porque os dois estão certos parte do tempo. O erro a evitar é usar o primeiro onde o segundo é necessário e ler o teste verde como prova.