Jak stworzyć plik o określonym rozmiarze

Windows

fsutil oraz wersja w PowerShellu, która nie potrzebuje niczego dodatkowego

fsutil jest częścią Windows. Przyjmuje rozmiar w bajtach, więc liczbę trzeba wyliczyć wcześniej - 10 MB to 10485760, 100 MB to 104857600, a 1 GB to 1073741824.

fsutil file createnew test10mb.bin 10485760

Zmierzone na Windows 11: działa ze zwykłego wiersza poleceń, bez podniesionych uprawnień, a plik wychodzi na dokładnie 10485760 bajtów.

PowerShell zrobi to samo bez wołania innego programu i rozumie jednostki:

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

10MB w PowerShellu znaczy 10485760 bajtów, czyli to samo liczenie po 1024, którego używa Eksplorator - oba polecenia dają więc ten sam rozmiar.

Linux

dd, truncate i fallocate, oraz różnica, na której ludzie się przejeżdżają

dd zna każdy. Naprawdę zapisuje bajty:

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

truncate jest natychmiastowy i właśnie w tym rzecz. Zmierzone na Alpine Linux: plik melduje 10485760 bajtów i zajmuje zero bloków - to plik rzadki. Cokolwiek go czyta, dostaje dziesięć megabajtów zer, ale dysk nigdy nie oddał tego miejsca:

truncate -s 10M test10mb.bin

Do testu limitu uploadu to bez znaczenia, do testu limitu miejsca na dysku - mylące. fallocate jest tym, po co sięgnąć, gdy miejsce ma być prawdziwe:

fallocate -l 10M test10mb.bin

A gdy zawartość ma się nie kompresować, żeby archiwizator nie zmniejszył jej z powrotem:

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

macOS

mkfile, który nie jest rzadki, i dwa znane skądinąd

macOS ma mkfile. Zmierzone na macOS 26.6.2: 10485760 bajtów i 20480 bloków, czyli miejsce jest naprawdę przydzielone, a nie tylko obiecane:

mkfile 10m test10mb.bin

dd i truncate też tam są i zachowują się tak jak na Linuksie:

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

Gdzie to przestaje wystarczać

Plik właściwego rozmiaru to nie to samo co plik właściwego rodzaju

Wszystkie polecenia wyżej dają blok zer. To wystarcza, dopóki testowana rzecz patrzy wyłącznie na rozmiar - limit uploadu, limit miejsca, transfer. Przestaje wystarczać w chwili, w której cokolwiek ten plik otwiera.

Zmierzone, i warto to zrobić samemu: zrób plik 2 MB przez fsutil, nazwij go photo.png i podaj bibliotece graficznej. Pillow odpowiada cannot identify image file. To nie jest PNG. Nigdy nim nie był - tak mówiła tylko nazwa.

To znaczy więcej, niż brzmi, bo chodzi o to, w którą stronę test wtedy pada. Twój endpoint odrzuca plik, test świeci na zielono, a Ty stwierdzasz, że limit rozmiaru działa. Nie odrzucił go za rozmiar. Odrzucił, bo bajty nie były obrazem - a reguła, którą chciałeś sprawdzić, nigdy nie została osiągnięta.

• parser odrzuca plik, zanim ktokolwiek spojrzy na regułę rozmiaru
• pada generowanie miniatury, a błąd, który czytasz, jest o miniaturze
• antywirus albo kontrola treści odrzucają go z trzeciego powodu
• przeglądarka nie pokazuje nic i nikt nie wie, czy to jest ta usterka

Druga droga

Prawdziwy plik tego formatu, o dokładnie zamówionym rozmiarze

To robi Testing Files Generator. Plik jest prawdziwym plikiem swojego formatu - otwiera się w programie, do którego należy - i ma dokładnie tyle bajtów, o ile poprosiłeś, co do jednego:

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

Poproś o rozmiar nieosiągalny dla formatu, a dostaniesz błąd nazywający minimum i jego powód, nigdy plik o innym rozmiarze. Strona formatów wypisuje każdy format razem z najmniejszym plikiem, jaki potrafi zrobić.

A limit to trzy przypadki testowe, nie jeden, więc narzędzie buduje wszystkie trzy:

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

Dostajesz 10485759, 10485760 i 10485761 bajtów oraz manifest mówiący, który z nich system ma przyjąć, a który odrzucić. Strona zastosowań przechodzi przez to i przez cztery inne zadania, pod które to powstało.

Darmowe i otwarte, GPL-3.0. Bez zakładania konta. Binarki nie są jeszcze podpisane, więc system ostrzeże przy pierwszym uruchomieniu - nota wydania mówi dokładnie, czego się spodziewać.

Czego więc użyć?

• Polecenia systemowego

  Gdy nic tego pliku nie otwiera. Test limitu rozmiaru na endpoincie, który sprawdza rozmiar najpierw, transfer, limit miejsca, zapełniony dysk. To jedna linijka i jest już zainstalowana.

• Prawdziwego generatora

  Gdy cokolwiek plik parsuje, renderuje, importuje albo rozpakowuje - i gdy te same dane testowe mają być jutro, na innej maszynie, co do bajta takie same.

Obie drogi są na tej stronie, bo obie bywają właściwe. Błędem wartym uniknięcia jest użycie pierwszej tam, gdzie potrzebna jest druga, i odczytanie zielonego testu jako dowodu.