How to Archive FreeDOS Files Without Losing Names or Metadata

Work from a backup, never the only copy, and decide up front whether the archive must round-trip on plain DOS with 8.3 names or needs to preserve long filenames through DOSLFN and a compatible archiving tool — that single decision shapes almost every step that follows.

Step 1: decide whether long filenames are actually in play

FreeDOS itself operates on 8.3 names internally even when a long-filename layer is loaded — DOSLFN, the commonly used LFN driver for plain DOS, provides the long-filename API and translates names for DIR and LFN-aware applications, but most FreeDOS utilities still see and manipulate the underlying 8.3 name directly. If any file you’re archiving has a name only representable as a long filename, confirm your archiving tool is genuinely LFN-aware rather than assuming ZIP support implies it — a tool that only understands 8.3 will silently archive the truncated alias instead of the full name.

Step 2: record the codepage before you archive anything

Filenames containing accented or non-ASCII characters are stored according to the active codepage at creation time. Extracting that same archive later under a different codepage, or on a modern host with a different default encoding, can decode those bytes into completely different-looking characters. Note the codepage you were running under directly alongside the archive itself — a plain text note in the same directory is enough, and saves real guesswork later.

Step 3: create the archive with adequate temporary space

PKZIP -A archive.zip *.*

Confirm the target disk or partition has enough free space for the archive plus its own temporary working files before starting — an archiver running out of space mid-operation on constrained period hardware can leave a corrupt, partially-written archive behind rather than failing cleanly.

Step 4: run the tool’s own integrity test immediately

PKUNZIP -t archive.zip

Testing immediately after creation, while the source files are still present and unmodified, catches a bad archive before you’ve relied on it as your only copy of anything.

Step 5: extract to a separate directory and compare

Extract into a directory distinct from the original files, then compare file count, individual sizes, and — where a hashing utility is available — content hashes between the original files and the extracted copies. A file count and total-size match alone doesn’t guarantee byte-for-byte content integrity; a hash comparison does.

Step 6: only split archives when the destination genuinely requires it

Splitting into multiple volumes adds complexity and another way for the archive to go bad (a missing or corrupt middle volume breaks the entire set) — reserve it for cases where the receiving medium’s own capacity genuinely requires it, and always keep every volume of a split archive together as a single unit.

Choosing between ZIP and 7-Zip deliberately

ZIP remains the safer default specifically for DOS-era compatibility — nearly every DOS archiving tool, contemporary and modern, can read it. A period-appropriate 7-Zip build can compress meaningfully better, but at the cost of higher memory requirements and a narrower field of compatible extractors, which matters more on genuinely constrained hardware than the compression ratio does. An archive is not a backup until a separate machine has actually restored it successfully — creation and a self-test on the same system that made the archive doesn’t prove that.

When a self-extracting archive is actually the better choice

For distributing an archive to a machine that may not have a compatible unzip tool available at all, a self-extracting archive — a .EXE file that bundles the extraction logic together with the compressed data — avoids that dependency entirely at the cost of a larger file and, since it’s an executable, a step of trust the recipient has to be willing to extend before running it. Reserve self-extracting archives specifically for distribution scenarios where you can’t assume the destination already has a matching extraction tool installed; for ordinary backup and archival use on a system you control, a plain archive plus a known-available extractor is simpler and doesn’t carry that same trust requirement.

Verifying on the actual destination system, not just the source

An archive that tests and extracts cleanly on the machine that created it hasn’t yet proven it will do the same somewhere else — codepage handling, available memory, and even subtly different tool versions can behave differently on a second machine. Whenever an archive is meant to move to different hardware, confirm the full extract-and-verify cycle on that actual destination system before considering the backup or transfer complete, not only on the system where it was originally packed. Related: Writing Batch Files on FreeDOS · Device Drivers on FreeDOS: How .SYS Files Extend the Kernel

Sources: