FreeDOS TREE and pdTree: Build a Readable Directory Inventory

FreeDOS TREE gives an operator a visual outline of directories below a selected drive or path. With /F it also lists file names; with /A it uses ASCII characters for the branches, which is useful when the output must survive a printer, text file, serial transfer, or a system with a different code page. The separately documented pdTree program offers additional options, but its DOS and Win32 builds do not necessarily share every behavior.

A tree display is an inventory view, not a backup, filesystem check, or stable object identifier. It shows names reachable through the current DOS path and directory APIs at the moment the command runs. It cannot prove file contents, detect every damaged cluster chain, show files that the current driver cannot enumerate, or make the drive letter a durable identity. Use TREE to answer “what is organized beneath this path?” and use other tools to answer integrity and recovery questions.

Choose a narrow root before traversing

The standard command accepts an optional drive and path. If none is given, it starts at the current directory. Begin with an explicit root so a script or operator does not accidentally inventory the wrong drive:

TREE C:\PROJECT
TREE C:\PROJECT /F
TREE C:\PROJECT /A /F

The first form shows directories. The second includes file names. The third produces an ASCII-oriented listing that is easier to redirect or exchange when the recipient’s display does not use the same line-drawing glyphs. The /A option changes presentation characters, not directory names or file contents. Confirm that the report begins at the requested path before using it in a migration or audit.

Do not begin with a bare TREE on a machine with several disks, mounted images, redirected drives, or a changed current directory. The current drive and the current directory are separate pieces of DOS state. A path without a drive letter is resolved relative to the active context, and a tool invoked from a batch file may inherit a different context than the interactive prompt. Record the root explicitly and capture the command line with the output.

On a large volume, use TREE without /F for a structural overview first. Adding every filename can produce a report much larger than the directory skeleton. This makes paging and review harder and can consume disk space if output is redirected. Increase the scope only when file presence is part of the question. If only a particular subdirectory matters, pass that root rather than traversing the whole volume and filtering a giant listing afterward.

Distinguish TREE from pdTree

The FreeDOS help documents standard TREE and pdTree in the same reference but calls out extra pdTree options that are not available in standard TREE. Standard TREE documents /F and /A. pdTree documents /V for version information and /S to use short names only in the DOS build; the latter disables the long-filename API for its enumeration. Its /P page option is described with separate DOS and Win32 behavior. Do not assume a switch documented for pdTree is accepted by a program named TREE on another system.

Resolve the executable before depending on a feature. Check the installed package, path, and program’s own help. If a machine has several utilities named TREE, call the intended executable by full path and record its version. A command that runs successfully but silently ignores an option is not an adequate compatibility test.

Long-name visibility depends on the filesystem and the API layer available to the program. The pdTree package description says it can use long names when the LFN API is present. Its /S option is a deliberate short-name mode for DOS and disables that interface. Therefore an inventory with readable long names and a later inventory showing 8.3 aliases may represent different enumeration modes, not a mass rename. Conversely, a missing long name can indicate that the LFN driver was unavailable or not active in that boot profile.

Keep the mode consistent between comparison runs. Record whether DOSLFN or another LFN provider was loaded, the pdTree/TREE version, and whether short-name mode was enabled. When interoperating with older software, include short names in the separately collected metadata if the chosen inventory tool exposes them; do not infer aliases from the display form.

Use output modes for the recipient

For a human in a compatible text display, the default branch glyphs can be easy to scan. For plain text, printer output, archival notes, or a link through a remote console, prefer /A. The output may still contain characters in the actual filenames that are not represented identically under another code page. Do not confuse tree-drawing symbols with filename encoding.

A basic capture can be made with the shell:

TREE C:\PROJECT /A /F > C:\REPORTS\PROJECT.TXT
MORE C:\REPORTS\PROJECT.TXT

Choose a fresh output filename and a destination that exists and has sufficient free space. DOS redirection with > replaces an existing file, so never point this command at the only source copy or a report that must be preserved. If a prior report matters, use a new name or archive it first. Check the final file’s existence, nonzero size, and last lines; the screen showing a prompt again does not establish that a redirected write completed correctly.

Piping to MORE is convenient for interactive review:

TREE C:\PROJECT /A /F | MORE

The FreeDOS reference documents TREE output through MORE as a paging workflow. The pipe displays the stream, but it is not a durable capture and does not create an independent log. For evidence or before/after comparison, save an output file and page through the saved report afterward. If a process exit code matters, test and record how the exact shell propagates status through a pipe rather than assuming modern pipeline semantics.

Interpret the result as a traversal, not a filesystem truth

TREE output depends on what the current DOS environment can see. A drive letter may be assigned to a partition, a RAM disk, a substituted path, a network redirector, or a removable device. Drivers and startup order can change which letters exist. A tree rooted at D: is therefore a description of the namespace at capture time, not proof that D: will refer to the same physical or virtual medium on the next boot.

Enumeration can also change while files are being created, renamed, or deleted. A concurrently modified directory may yield a mixed snapshot or an error, depending on the implementation and filesystem. Stop writers during a high-confidence inventory. Preserve the command output with a timestamp, the selected volume information, the software and driver versions, and a manifest of file hashes if content integrity is required.

A directory outline does not prove that each listed file is readable. It does not validate byte lengths or cluster chains, compare two media contents, or establish that an omitted file has been deleted rather than hidden by an attribute/API filter. For data migration, combine TREE with an explicit copy manifest, a byte or checksum comparison, and a separate test that the destination application can open the required files.

Avoid expensive or misleading traversals

Recursive listing with /F on the root of a large or slow disk can take time and generate overwhelming output. On removable media, confirm the correct disk is inserted before starting. On a failing disk, repeated directory traversal can stress the medium; image it or use a recovery strategy appropriate to the risk before issuing broad scans. TREE is not a recovery utility and should not be used as the first test on a physically unstable disk.

If the output seems incomplete, compare a limited known subdirectory, test with and without /F, inspect attributes or LFN availability, and run a different read-only listing tool. Do not immediately assume data loss. A typo in the root, a short-name setting, a disconnected network mapping, a DOS path limit, or a utility version mismatch may explain the difference.

For a portable report, avoid treating the visual indentation as a machine-readable manifest. Filenames can contain spaces and code-page-sensitive characters; a tree diagram is optimized for people, not parsers. Use a tool whose output format specifies escaping and record delimiters when downstream software will consume the listing.

Acceptance checks

Before adopting TREE as an operational inventory step, create a disposable directory tree containing an empty directory, a nested directory, files in several branches, a long filename if the LFN layer is part of the target, and representative non-ASCII characters. Run standard TREE, TREE /F, and TREE /A /F. Confirm the selected root, file visibility, glyph choice, and how the output behaves when redirected and piped.

Repeat with the exact executable and boot profile used in production. For pdTree, test each option against its own help and distinguish DOS from Win32 behavior. Save reports to fresh paths and compare them with a known expected structure. An acceptable inventory is one that names the right root, exposes the required names under a documented LFN mode, and has an output format the recipient can read. It remains only one layer of a complete backup or forensic record.

Related:

Sources: