So erstellst du eine Datei in exakter Größe

Jedes System hat dafür einen Befehl, alle drei stehen unten. Sie liefern dir eine Datei mit genau der richtigen Byte-Zahl - und für viele Tests ist das alles, was du brauchst. Jeder Befehl auf dieser Seite wurde vor der Veröffentlichung ausgeführt, auf dem System, zu dem er gehört.

Die kurze Antwort

Windows: fsutil file createnew name 10485760. Linux: dd if=/dev/zero of=name bs=1M count=10. macOS: mkfile 10m name. Größen werden in Bytes angegeben, und 10 MB, so gezählt wie dein Dateimanager zählt, sind 10485760 davon.

Windows

fsutil und eine PowerShell-Variante, die nichts Zusätzliches braucht

fsutil gehört zu Windows. Es nimmt die Größe in Bytes, rechne die Zahl also vorher aus - 10 MB sind 10485760, 100 MB sind 104857600, 1 GB ist 1073741824.

fsutil file createnew test10mb.bin 10485760

Gemessen unter Windows 11: Es funktioniert in einer normalen Eingabeaufforderung und braucht keine erhöhten Rechte, und die Datei hat genau 10485760 Bytes.

PowerShell kann dasselbe, ohne ein anderes Programm aufzurufen, und versteht Einheiten:

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

10MB bedeutet in PowerShell 10485760 Bytes, dieselbe Zählung auf 1024er-Basis, die der Explorer verwendet, die beiden Befehle oben erzeugen also dieselbe Größe.

Linux

dd, truncate und fallocate und der Unterschied, der Leute erwischt

dd kennt jeder. Es schreibt die Bytes wirklich:

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

truncate ist sofort fertig, und genau das ist der Haken. Gemessen unter Alpine Linux meldet die Datei 10485760 Bytes und belegt null Blöcke - sie ist eine Sparse-Datei. Wer sie liest, bekommt zehn Megabyte Nullen, aber der Datenträger hat den Platz nie hergegeben:

truncate -s 10M test10mb.bin

Das ist für den Test eines Upload-Limits in Ordnung und für den Test einer Datenträgerquote irreführend. fallocate ist das Mittel der Wahl, wenn der Platz wirklich belegt sein muss:

fallocate -l 10M test10mb.bin

Und wenn der Inhalt inkompressibel sein muss, damit ein Archivierer ihn nicht wieder zusammendrücken kann:

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

macOS

mkfile, das nicht sparse ist, und die beiden, die du schon kennst

macOS liefert mkfile mit. Gemessen unter macOS 26.6.2: 10485760 Bytes und 20480 Blöcke, der Platz ist also wirklich belegt statt nur versprochen:

mkfile 10m test10mb.bin

dd und truncate gibt es ebenfalls, und sie verhalten sich wie unter Linux:

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

Wo das nicht mehr reicht

Eine Datei in der richtigen Größe ist keine Datei der richtigen Art

Alles oben Genannte liefert dir einen Block aus Nullen. Das reicht, wenn das Getestete nur auf die Größe schaut - ein Upload-Limit, eine Quote, eine Übertragung. Es reicht nicht mehr, sobald irgendetwas die Datei öffnet.

Gemessen, und es lohnt sich, das selbst zu probieren: Erzeuge mit fsutil eine 2-MB-Datei, nenne sie photo.png und gib sie einer Bildbibliothek. Pillow antwortet cannot identify image file. Es ist kein PNG. Es war nie eines - nur der Name behauptete es.

Das ist wichtiger, als es klingt, wegen der Richtung, in der der Test dann fehlschlägt. Dein Upload-Endpunkt weist die Datei ab, dein Test wird grün, und du schließt, dass das Größenlimit funktioniert. Er hat sie nicht wegen der Größe abgewiesen. Er hat sie abgewiesen, weil die Bytes kein Bild waren, und die Regel, die du testen wolltest, wurde nie erreicht.

ein Parser weist sie ab, bevor eine Größenregel angesehen wird
ein Vorschauschritt schlägt fehl, und der Fehler, den du liest, betrifft die Vorschau
ein Virenscanner oder eine Inhaltsprüfung lehnt sie aus einem dritten Grund ab
ein Viewer zeigt nichts an, und niemand kann sagen, ob das der Fehler ist

Der andere Weg

Eine echte Datei dieses Formats, in genau der Größe, die du verlangt hast

Das ist es, was Testing Files Generator tut. Die Datei ist eine echte ihres Formats - sie öffnet sich in der Software, zu der sie gehört - und hat die exakte Byte-Zahl, die du verlangt hast, auf das Byte genau:

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

Verlange eine Größe, die ein Format nicht erreichen kann, und du bekommst einen Fehler, der die Untergrenze und ihren Grund nennt, nie eine Datei in der falschen Größe. Die Formate-Seite listet jedes Format mit der kleinsten Datei auf, die es erzeugen kann.

Und ein Limit sind drei Testfälle statt einem, deshalb baut das Tool alle drei:

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

Das ergibt 10485759, 10485760 und 10485761 Bytes und ein Manifest, das sagt, welche davon dein System akzeptieren und welche es ablehnen soll. Die Anwendungsfälle-Seite geht das und vier weitere Aufgaben durch, für die es gebaut ist.

Herunterladen Quellcode ansehen

Kostenlos und Open Source, GPL-3.0. Keine Anmeldung nötig. Die Downloads für Windows und macOS sind signiert und starten ohne Warnung.

Was solltest du also verwenden?

Den Systembefehl verwenden

Wenn nichts die Datei öffnet. Ein Größenlimit an einem Endpunkt testen, der zuerst die Größe prüft, eine Übertragung, eine Quote, ein voller Datenträger. Es ist eine Zeile, und es ist schon installiert.
Einen echten Generator verwenden

Wenn irgendetwas die Datei parst, rendert, importiert oder entpackt - und wenn du morgen auf einem anderen Rechner dieselben Fixtures brauchst, Byte für Byte.

Beides steht auf dieser Seite, weil beides manchmal richtig ist. Der Fehler, den es zu vermeiden gilt, ist, das Erste zu verwenden, wo das Zweite nötig ist, und den grünen Test als Beweis zu lesen.