Cómo crear un archivo de un tamaño exacto

Windows

fsutil, y una versión de PowerShell que no necesita nada extra

fsutil viene con Windows. Toma el tamaño en bytes, así que calcula antes el número - 10 MB son 10485760, 100 MB son 104857600, 1 GB es 1073741824.

fsutil file createnew test10mb.bin 10485760

Medido en Windows 11: funciona desde un símbolo del sistema normal sin necesitar uno elevado, y el archivo sale con exactamente 10485760 bytes.

PowerShell puede hacer lo mismo sin llamar a otro programa, y entiende unidades:

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

10MB en PowerShell significa 10485760 bytes, el mismo recuento en base 1024 que usa el Explorador, así que los dos comandos anteriores producen el mismo tamaño.

Linux

dd, truncate y fallocate, y la diferencia que pilla a la gente

dd es el que todo el mundo conoce. Escribe los bytes de verdad:

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

truncate es instantáneo, y esa es la trampa. Medido en Alpine Linux, el archivo informa de 10485760 bytes y ocupa cero bloques - es un archivo disperso. Cualquier cosa que lo lea obtiene diez megabytes de ceros, pero el disco nunca cedió el espacio:

truncate -s 10M test10mb.bin

Eso sirve para probar un límite de subida y engaña para probar una cuota de disco. fallocate es el que hay que usar cuando el espacio tiene que ser real:

fallocate -l 10M test10mb.bin

Y cuando el contenido tiene que ser incompresible, para que un compresor no pueda volver a reducirlo:

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

macOS

mkfile, que no es disperso, y los dos que ya conoces

macOS incluye mkfile. Medido en macOS 26.6.2: 10485760 bytes y 20480 bloques, así que el espacio está realmente asignado en lugar de prometido:

mkfile 10m test10mb.bin

dd y truncate también están y se comportan como en Linux:

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

Dónde esto deja de funcionar

Un archivo del tamaño correcto no es un archivo del tipo correcto

Todo lo anterior te da un bloque de ceros. Eso basta cuando lo que se prueba solo mira el tamaño - un límite de subida, una cuota, una transferencia. Deja de bastar en cuanto algo abre el archivo.

Medido, y merece la pena que lo hagas tú: crea un archivo de 2 MB con fsutil, llámalo photo.png y pásaselo a una biblioteca de imágenes. Pillow responde cannot identify image file. No es un PNG. Nunca lo fue - solo lo decía el nombre.

Eso importa más de lo que parece, por la forma en que la prueba falla entonces. Tu endpoint de subida rechaza el archivo, tu prueba se pone en verde y concluyes que el límite de tamaño funciona. No lo rechazó por el tamaño. Lo rechazó porque los bytes no eran una imagen, y la regla que querías probar nunca se alcanzó.

• un analizador lo rechaza antes de mirar ninguna regla de tamaño
• falla un paso de miniaturas y el error que lees trata de la miniatura
• un antivirus o una comprobación de contenido lo rechaza por un tercer motivo
• un visor no muestra nada, y nadie puede saber si ese es el fallo

La otra vía

Un archivo real de ese formato, con exactamente el tamaño que pediste

Esto es lo que hace Testing Files Generator. El archivo es uno genuino de su formato - se abre en el programa que le corresponde - y tiene el número exacto de bytes que pediste, al byte:

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

Pide un tamaño que un formato no puede alcanzar y obtienes un error que nombra el suelo y su motivo, nunca un archivo del tamaño equivocado. La página de formatos lista cada formato con el archivo más pequeño que puede producir.

Y un límite son tres casos de prueba y no uno, así que la herramienta construye los tres:

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

Eso te da 10485759, 10485760 y 10485761 bytes, y un manifiesto que dice cuáles debe aceptar tu sistema y cuáles rechazar. La página de casos de uso repasa eso y otras cuatro tareas para las que está pensada.

Gratuito y de código abierto, GPL-3.0. Sin registro. Las descargas de Windows y macOS están firmadas y se inician sin advertencias.

Entonces, ¿cuál debes usar?

• Usa el comando del sistema

  Cuando nada abre el archivo. Probar un límite de tamaño en un endpoint que comprueba antes el tamaño, una transferencia, una cuota, un disco lleno. Es una línea y ya está instalado.

• Usa un generador real

  Cuando algo analiza, renderiza, importa o extrae el archivo - y cuando necesitas los mismos fixtures mañana, en otra máquina, byte a byte.

Ambos están en esta página porque ambos aciertan parte del tiempo. El error que conviene evitar es usar el primero donde hace falta el segundo y leer la prueba en verde como una demostración.