A line from an archive listing

Files and text

One row from a printed index of an archive, laid out as a fixed sequence of columns that ends with a path.

The shape

A listing line is a table row rendered as text. The rendering varies, but the field order is remarkably stable: something describing attributes, then a size, then a date, then the path. The path goes last for a practical reason, which is that it is the only field allowed to contain spaces, so anything after it could not be told apart from it.

Field order

attributes, size, date and time, path, reading left to right

Attribute field

a short run of letters and hyphens of constant width, or a compact group of single letter flags

Size field

digits only, right aligned so the units line up down the page; sometimes two size columns, stored and original

Date field

a date, usually followed by a time, at a constant width

Path field

last, may contain spaces, may contain separators, may end in a separator

Separator between fields

either constant column positions or runs of one or more spaces, and the difference matters

Directory rows

marked by an attribute flag, a trailing separator on the path, or both

skeleton: x is one character, # is one digit

xxxxxxxxxx  #####  ####-##-## ##:##  path/to/name

ten attribute characters, a right aligned size,
a ten character date, a five character time, path

-rw-r--r--   1234  0000-00-00 00:00  example/notes.txt
-rw-r--r--   5678  0000-00-00 00:00  example/sub/example.txt
drwxr-xr-x      0  0000-00-00 00:00  example/sub/
-rw-r--r--    901  0000-00-00 00:00  example/two words.txt

Fixed columns and whitespace columns

Two rendering styles look almost identical and behave differently. In a fixed width listing, each field occupies a reserved number of character positions, and you can read a field by counting across from the left edge. Values that are shorter than their column are padded. Values that are longer overflow, and when they do they run into the neighbouring column with no space between them, which is how a size and a date sometimes appear welded together on one row of an otherwise tidy listing.

In a whitespace separated listing there are no reserved positions. Fields are divided by runs of spaces, the runs vary in length, and the columns only appear to line up because the values happen to be similar widths. Reading such a listing means counting field boundaries rather than character positions, and the path is everything after the last boundary you care about.

The practical difference shows up on exactly two kinds of row. A path containing spaces is unambiguous in a fixed width listing and ambiguous in a whitespace separated one, unless you know in advance how many fields precede the path. A very large size or a very long attribute string is unambiguous in a whitespace listing and destroys the alignment of a fixed width one. When a listing suddenly becomes hard to read, one of those two things has usually happened.

How to check it by eye

What a wrong shape means

Ragged left edges are the commonest fault and the least interesting. A listing pasted into a field that collapsed runs of spaces loses its alignment entirely while keeping every value intact. The rows are still readable, they simply no longer form columns, and the fix is to count fields rather than positions.

Letters inside the size column mean either the listing prints sizes with units attached, which is a formatting choice, or two fields have merged. Look at the row above and below: if their size columns are plain digits, the odd row has overflowed.

A path appearing before the size means you are reading a listing style this card does not describe, and the field order should be worked out from the header row if there is one rather than assumed.

A row with fewer fields than its neighbours has usually lost a field to a line break somewhere upstream, which is a transport problem covered on the lost line breaks card. A row split across two display lines is one row, not two, and reading it as two produces nonsense.

What a path column can tell you

This is where a listing gives you something a bare filename cannot. A filename is one label. A path is a sequence of labels with a structure, and the structure is visible.

Three properties of the path column are worth reading deliberately. The first is depth: how many separators a path contains, and whether the depth is consistent across the listing or whether one entry sits far below the rest. The second is rooting: whether paths begin with a separator, which describes them as absolute rather than relative to wherever the archive is opened. The third is upward movement: whether any path contains a segment of two dots, which names a parent rather than a child and therefore describes a position above the point it is measured from.

All three are facts about the text in the column. An entry whose path climbs above the top of the archive is an unusual shape and is worth noticing for the same reason any unusual shape is: it tells you the listing is not the plain tree it appears to be. What it does not tell you is anything about what would happen anywhere, since this site describes shapes and does not model behaviour.

Where paths matter most is in the gap between a listing and a single name. A file extracted and then examined alone has lost its path; the listing is the only place the structure was ever visible. Reading the column before the structure is discarded is the entire practical value of this card.

What a correct shape does not prove

A listing is text produced by reading fields stored inside the archive. Those fields were written when the archive was built, by whatever built it, and they are stored as data rather than derived from anything at the moment you look.

• The size column is a recorded number. It describes what the header says, and a header can say anything.
• The date column is a recorded field with no relationship to when the archive reached you or when the contents were created.
• The attribute column describes flags stored in the header, which some systems ignore entirely when extracting.
• A path in the listing does not establish that anything with that name is present, complete or readable.
• Tidy alignment establishes only that the values happened to fit their columns.
• A listing does not establish that the entries relate to each other, that they came from one place, or that the archive is intact.
• Nothing in a listing identifies who assembled it, and no column exists for that.

Treat a listing as a table of claims, uniformly formatted. Uniform formatting is evidence of a tool, not of accuracy.

What this card is not

How the last component of a path is read as a name, and which part of it counts as a type, is on the extension card. What a digest printed beside an archive establishes, and what it does not, is on the file hash card. This card covers only the shape of a printed row, and describes no archive format in particular.