FreeDOS DIR Semantics: Wildcards, Attributes, Ordering, and Reproducible Listings

FreeDOS DIR is a built-in FreeCOM command, not a separate executable that can be replaced independently of the command shell. It lists directory entries, expands file patterns, optionally traverses subdirectories, filters by attributes, and sorts the displayed results. A DIR listing is often the first evidence collected during DOS troubleshooting, so its defaults and inherited settings must be understood before an operator treats “not shown” as “not present.”

The listing is a query against the DOS namespace as it exists at that moment. It is not a checksum, file-content inspection, volume identity proof, or filesystem repair. Hidden and system entries may be omitted by a default invocation; long-name behavior depends on the environment; and sort output can change if FreeCOM lacks enough memory. Reproducible use starts by removing hidden command defaults from the investigation and making the path, attributes, recursion, and output style explicit.

Establish which DIR is running

DIR is internal to COMMAND.COM/FreeCOM, so an executable of the same name elsewhere does not define the behavior of the built-in command. Record the shell version and inspect the environment variable DIRCMD, which FreeCOM parses before processing the explicit arguments. DIRCMD can supply persistent options and make a bare command appear different from what a script author expects.

At a prompt, inspect the variable and then test a narrow path:

SET DIRCMD
DIR C:\FREEDOS\BIN
DIR C:\FREEDOS\BIN /B

FreeCOM documentation describes /O:U as the unsorted order option, which can cancel an inherited sort selection. Do not remove a useful global DIRCMD setting just to produce one clean report; override it explicitly when the installed implementation supports the required syntax, and save the original value in the test notes. Position of options is documented as not significant for the examples in the FreeDOS help, but verify unusual combinations on the target shell.

Constrain wildcard expansion and path scope

A pattern can contain a drive, path, and filename component. When no pattern is supplied, DIR displays the current working directory. FreeDOS help says that a directory path is essentially treated like directory*.* and that wildcard patterns can match files and directories. This makes an explicit path important when the current directory may be inherited from a batch file, a shell submenu, or a per-drive remembered directory.

Prefer a fully qualified root:

DIR C:\PROJECT\*.CFG
DIR C:\PROJECT\*.CFG C:\PROJECT\*.INI
DIR C:\PROJECT\ /S /B

When multiple patterns are specified, the documentation says they are processed in sequence, so results for one pattern can appear as a group before results for the next. Do not assume that multiple filespecs are merged into one globally sorted set. If order and grouping matter, run one pattern at a time and retain the commands with their outputs.

The broad /S switch recursively displays subdirectories. This can produce a long report and may expose a much larger set than a top-level listing. Begin without recursion, inspect the candidate root, then add /S only when required. Confirm that the volume is the intended target and that the recursive search will not traverse a network or removable device unintentionally.

The FreeDOS DIR reference documents /A for attribute filtering. The set includes read-only, hidden, system, directory, and archive states; a leading minus selects entries where an attribute is not set. The reference also describes /A without a value as including hidden and system files in wildcard matching. Therefore a plain DIR that does not show a file is not proof that the file is absent.

Use explicit attribute selection when you need a complete investigation:

DIR C:\PROJECT\ /A
DIR C:\PROJECT\ /A:H /S
DIR C:\PROJECT\ /A:-H /A:-S /S

Check exact compound syntax on the installed FreeCOM because the source documentation’s notation may represent alternatives differently from a particular parser. For a forensic comparison, run a known test directory containing visible, hidden, system, read-only, and subdirectory entries before relying on a complex filter. Save the full unfiltered report alongside any filtered report so exclusions remain reviewable.

An attribute is a DOS metadata flag, not an access-control boundary. A visible or hidden result does not establish who can read or alter the bytes. DIR reports names and metadata the kernel exposes; use appropriate file-content, checksum, or media analysis for stronger conclusions.

Choose an output form for the consumer

The default presentation includes names and descriptive fields. /W displays a wide listing and suppresses details such as size and date. /B displays names only, and when combined with /S it emits absolute paths according to the FreeDOS reference. /L prints names in lowercase; /Y or /4 requests a four-digit year. Use a format whose meaning matches the question rather than assuming that a compact output contains all metadata.

For a path-only inventory:

DIR C:\PROJECT\ /S /B > C:\REPORTS\PROJECT-PATHS.TXT

Choose a fresh output path. Redirection with > truncates an existing destination, so never overwrite a prior evidence file or use a path inside a target tree if that could confuse subsequent recursive scans. Check the resulting file and record the exact command. For dates, request a four-digit year so a human reader does not have to guess which century a two-digit year denotes.

Names alone are not stable identities. Case can be displayed differently, short and long names may refer to the same entry, and a path can resolve to a different volume after drive assignments change. If a report will be consumed by another program, verify its encoding, line delimiters, and handling of unusual filenames. DIR’s human-oriented display does not promise an escaped machine-readable format.

Understand ordering and memory pressure

The /O option sorts by selected attributes including date/time, extension, directory grouping, name, or size, and a hyphen can reverse a supported order. Multiple order directives have precedence rules documented by FreeDOS: the last sort order within one /O expression wins, and the last /O option supersedes earlier /O options. Read the actual command carefully when DIRCMD also injects an order.

Sorting is not guaranteed to be complete for arbitrary directory sizes. The FreeDOS reference warns that entries are cached in memory before display and that if FreeCOM runs short of memory, sorting can be disabled or performed in chunks. A result that appears alphabetic in one environment may be partial or differently grouped in another. Do not use DIR order as a reliable chronological or lexical database index unless the exact workload and shell have been tested.

For a comparison, request /O:U when supported and sort the saved manifest with a tool designed for deterministic data processing on a host system. If the DOS output itself must be ordered, note whether it is a single global order or per-chunk output and validate the result against a small known set. Low conventional memory, resident utilities, long directory entries, and a large recursive walk can change the conditions under which sorting occurs.

Use dates and sizes as evidence with limits

DIR shows directory metadata, but FAT timestamps have limited precision and no stored timezone. A two-second time resolution, local-time assumptions, and clock adjustments can make two legitimate timestamps appear equal or out of sequence. Requesting a four-digit year removes one ambiguity, not every timestamp limitation. A listing alone is not a forensic timeline.

Displayed size is the logical file length reported by DOS, not allocated cluster space, physical sectors read, or a byte-for-byte validation. An empty file can be listed successfully while its contents are not useful, and a nonzero size does not prove its allocation chain is intact. Check representative file reads and checksums when content matters.

Volume labels and serial numbers may appear in listings, but neither makes the drive letter a permanent hardware reference. Verify the physical or virtual device through the environment that attached it, then use a known marker file and relevant volume details to reduce ambiguity. Keep that identity note with the listing.

A repeatable diagnostic sequence

For a new incident, record current drive and directory, shell build, DIRCMD, target path, and whether long-filename support is loaded. Run a narrow default listing, then a complete attribute-aware listing, and finally a recursive bare listing only if needed. Capture each form to a unique filename rather than reusing a single output that will erase earlier observations.

Test the command with a fixture tree containing wildcard near-matches, a hidden file, a system file, a directory, a long filename, different extensions, and equal timestamps. Compare the default output, /A filters, /B, /S, /W, and ordering. Re-run after reducing free memory only in a disposable environment to determine whether sorting changes on the target build. This makes shell-specific behavior visible before it affects an operational report.

Accept a listing as evidence only when its scope and omissions are documented. A trustworthy report states which command and options were run, which DIRCMD defaults were active, the root and current drive, the shell version, the LFN mode, and whether recursion or attribute filtering was applied. Pair it with hashes or a copy when contents matter. DIR can answer where DOS currently sees names; it cannot answer every question that a file listing invites.

Related:

Sources: