How to Archive FreeDOS Files Without Losing Names or Metadata

Define the round-trip requirement first: plain DOS with 8.3 names, FreeDOS with DOSLFN and an LFN-aware tool, or a modern destination. Work from a copy and keep the original until a separate restore has passed. Paths, names, attributes, timestamps, and compressed data may not behave identically across DOS-era and modern tools.

Step 1: decide whether long filenames are actually in play

Plain DOS conventionally exposes 8.3 names. FreeDOS documents DOSLFN as a driver that provides long-filename services to compatible applications, but loading it does not make every archiver LFN-aware. Test the exact ZIP tool against the target tree; do not assume every program sees the long name rather than its short alias. If strict compatibility matters more than retaining long names, normalize names deliberately and keep a manifest mapping original names to DOS-safe names. Check for alias collisions rather than accepting silent truncation.

Step 2: record the codepage before you archive anything

Non-ASCII filenames need an explicit round-trip test. ZIP producers and extractors can use legacy encodings or Unicode extra fields differently, and a DOS display codepage does not guarantee that each archiver preserves every name unchanged. Record the source codepage and tool versions; test actual names on the destination. Keep filename encoding distinct from the content bytes of a text file: changing display codepage does not itself convert the file’s contents.

Step 3: create the archive with adequate temporary space

ZIP -r ARCHIVE.ZIP PROJECT

FreeDOS’s ZIP utility documents -r for recursive directory traversal. Confirm the actual installed tool and its help because ZIP, PKZIP, and other utilities can differ. Check space for the completed archive and temporary output. Do not use an option that deletes or moves the source during first-time backup creation. In Info-ZIP, -m removes inputs after adding them and -l converts text line endings; avoid those for a baseline archive or byte-sensitive data.

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

UNZIP -t ARCHIVE.ZIP

Testing immediately after creation catches many damaged entries, but it does not prove that every intended file was included or that names will round-trip. Keep the source intact while checking both the container and the extracted result.

Step 5: extract to a separate directory and compare

Extract into a new, empty directory and compare file count, relative paths, individual sizes, and, where available, content hashes against a pre-archive manifest. FreeDOS UNZIP documents -d for selecting an extraction directory and -l for listing entries. A count and total-size match alone cannot identify a missing file offset by an extra one.

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 an archive format 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.

ZIP is a compatibility-oriented default, not a universal guarantee: DOS archivers differ by implementation and age, and newer compression methods, filename metadata, or long-name conventions may not be understood by an older extractor. Test with the exact receiving program. A different format such as 7-Zip is suitable only when both endpoints demonstrably support it and its memory and storage requirements fit the target.

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.

Build a manifest and distinguish integrity from authenticity

Before packing, list each relative path and expected byte length; record hashes when a trusted hash utility is available. Include empty directories or hidden/system files only when the use case requires them, and make that decision explicit. If an application is writing a file while the archive runs, the copy may be internally inconsistent even though the archiver reports no read error. Stop the application or use its documented backup/export procedure first.

ZIP entry CRCs can detect many accidental corruptions, but they are not cryptographic authenticity checks. For valuable transfers, calculate a SHA-256 digest of the finished archive and preserve it separately in a protected place. Recalculate it after copying or storing the archive. A digest that travels only beside an untrusted archive helps detect later bit rot but does not prove who published either item. Also retain provenance, tool version, creation date, and the intended restore procedure in a text sidecar.

Confirm the exact tool syntax and source safety

FreeDOS’s ZIP reference documents recursive traversal with -r, an integrity-test option, and the -m option that moves specified inputs by deleting them after archiving. Treat destructive switches cautiously; a first backup should never delete the only source copy. The ZIP documentation also describes -l line-ending conversion. Do not enable text conversion for executable, compressed, or otherwise byte-sensitive content. Some archiver builds differ, so use the help for the exact executable installed rather than copy syntax from a different PKZIP, ZIP, or desktop utility.

The UNZIP reference documents -t for testing compressed archive data, -l for listing entries, and -d to select a destination directory. A safe sample for an empty test directory is:

UNZIP -t ARCHIVE.ZIP
UNZIP -l ARCHIVE.ZIP
MD RESTORE
UNZIP ARCHIVE.ZIP -d RESTORE

This verifies more than a single successful create operation, but still compare the result against a manifest: count, relative names, file sizes, and hashes where possible. Opening representative restored files or running a read-only validation program helps catch issues that a container-level test cannot detect. Keep the original untouched until this restore is complete.

Treat names and attributes as a cross-platform contract

ZIP archives can carry paths, timestamps, file data, and extra attributes, but how those are exposed depends on the creator and extractor. DOS and Unix attributes do not have identical meanings; ownership, permissions, hidden/system flags, and executable bits may not map as expected. Preserve important installation details in a sidecar when the target’s extractor cannot represent them reliably.

For LFN use, load DOSLFN only as the installed documentation directs and verify that the specific archiver is LFN-aware. Test a directory containing a long name, a name with multiple dots, a name differing only by case, and a non-ASCII name if those occur in the real data. Extract on the real target filesystem: another tool may use a short alias, reject a name, or normalize it differently. Keep a mapping file for deliberate 8.3 renames instead of relying on implicit truncation.

Do not conflate a display codepage with text encoding. A codepage affects character interpretation in DOS tools, while a file can contain bytes in a different encoding or be entirely binary. Changing codepage during an archive workflow does not transcode file contents. For text files intended to be portable, document the encoding and line-ending convention, and avoid archiver options that rewrite line endings unless that transformation is explicitly wanted and separately verified.

Plan for limited disks and removable media

Check available capacity for both the archive and the restored data. A compressed archive can be small while its extracted tree is large; do not start extraction onto a nearly full volume. If a destination medium requires multiple archive parts, preserve every part together, record order, and test the whole set. A missing part can prevent restoration. Separate ZIP files are not necessarily equivalent to one split multi-volume archive; follow the tool’s own documented workflow.

For floppy or aging removable media, source read errors require a recovery workflow before archiving. Preserve an image or copy and record which sectors or files could not be read; then archive the recoverable copy. Compression cannot reconstruct bytes the drive failed to read. Store the result on independent media: a second directory or partition on the same physical disk does not protect against failure of that disk.

Define restore acceptance before calling it done

For an ordinary file transfer, require a successful archive test, a complete extraction into an empty destination, the expected inventory and sizes, and a matching digest where available. For a backup, add a restore performed from the separate storage device, preferably on a second machine or clean VM using the intended DOS, LFN driver, archiver, and filesystem. Open representative documents and validate important project data. Record any limitation, such as names reduced to 8.3 or timestamps not preserved, instead of calling the archive lossless.

Re-test after changing archive software, moving to another operating system, changing name support, or switching storage media. When updating an archive, inspect for stale entries: replacing changed files does not necessarily remove files deleted from the original tree. For a snapshot, a new archive under a new name makes rollback clearer than mutating the sole known-good copy. The reliable workflow stays reversible: preserve source, create, test, restore, compare, then decide whether old copies may be retired.

Related:

Sources: