Everyone knows a tar path is capped somewhere near 255 bytes. Almost nobody knows the cap is not the rule.
ustar stores a path in two fields: name (100 bytes) and prefix (155). They are joined by a slash that is never stored. So what has to fit is not the path — it is the two halves either side of some slash.
Check any path: https://dev48.infy.uk/solve/day73-tar-archive-reader.html
a 130-byte path with no slash after byte 100 → UNSTORABLE
a 256-byte path that splits 155 / 100 → fits in one block
GNU tar 1.35's own error message says max 256, not 255.
Scoring the folk rules
Over a 20,000-path corpus:
| model | wrong |
|---|---|
| "≤ 256 bytes" | 2,499 times — 34.83% of everything in the 101–256 band |
| "has a slash" | 2,074 of those refusals do contain a slash |
| "≤ 255 bytes" | 2,486 times |
Read that last row again. The wrong number scores better than the right one — 2,486 against 2,499 — purely because the 13 paths of exactly 256 bytes in this corpus all happen to be unsplittable. A benchmark that ranks these two models picks the one that is wrong about the boundary it is wrong about.
A refused name is not a refused archive
GNU tar reaches for the prefix field only under --format=ustar. In its own gnu and posix formats, the same 140-byte path becomes three blocks with a truncated 100-byte twin left in the name field.
So one archive presents two different file lists, and a reader that does not speak the extension writes a real file at a real — different — path. No error on either side.
Differential, in both directions
Every verdict on the page is checked against GNU tar 1.35 and Python 3.11 tarfile. They disagree with each other on eight live cells: one trailing slash, four ways of spelling a number, two off-by-one length fields, and six missing magic bytes — every one producing a different answer rather than an error.
The loudest one:
put an ASCII '+' in front of the size field
Python 3.11 tarfile → 10 bytes
GNU tar 1.35 → 951,617,749,834,222,966 bytes
GNU reads the sign as the 1990s base-256 header format and lists the member anyway.
8,369 verifier asserts, 3,922 in-page assertions, 0 failures. Vanilla JavaScript, one file, no build step.
Top comments (0)