FreeDOS REN: Plan Wildcard Renames Before Changing Directory Entries

FreeDOS REN, also named RENAME, changes a file or directory name without moving the source to an arbitrary destination path. Its destination pattern is interpreted as a new name within the source directory. Wildcards in the destination are substituted from the source name, which makes short batch transformations compact but also easy to misunderstand. The safe operating model is to enumerate the source set, calculate the output names, check for collisions, and change one disposable sample before running a broad pattern.

REN is not a copy command, a content conversion, or a cross-volume move. A successful rename says that the directory entry was changed under the current DOS filesystem interface; it does not prove that file contents are intact, that another application has closed the file, or that the new name is visible through every long-filename layer. Keep a verified backup when a naming operation would be difficult to reverse.

Keep source path and destination name separate

The FreeDOS reference shows a source filespec with a drive and path and a destination name without a path. For example:

REN C:\PROJECT\REPORT.TXT REPORT.OLD

This changes the name in the same directory. It does not specify a new directory or drive. If the task is to move files into a different directory, use a move operation whose semantics have been verified for the installed system, or copy into a staged destination, validate it, and remove the original only after the new copy is accepted.

Do not supply a destination that merely looks like a path and assume REN will relocate the source. FreeDOS documentation explicitly states that the destination must not contain a path specification. The classic INT 21h rename service also documents same-device restrictions. Cross-volume workflows therefore require a different command and separate integrity checks.

Before renaming, verify the current path, source drive, target directory entry, and application ownership. A file open by another application, a read-only state, a target name that already exists, or a filesystem/API limitation can make a rename fail. Record the exact error and stop rather than broadening permissions or changing attributes automatically.

Understand destination wildcard substitution

FreeDOS REN supports * and ? in file patterns. The help examples show that destination wildcard positions are replaced using characters from the source filename. For instance, changing matching DAT names to A*.* prepends A to the basename while retaining the rest of the matched name and extension according to that pattern:

DIR C:\PROJECT\*.DAT
REN C:\PROJECT\*.DAT A*.*
DIR C:\PROJECT\A*.DAT

That example is not a preview mode. The first DIR is a review step, REN performs the change, and the final DIR checks the visible result. Run the same transformation first in a copied test directory. A wildcard can match more entries than intended, and a destination pattern can cause two different source names to converge on one destination. Do not assume REN resolves collisions in a predictable, reversible order.

Question mark represents a single-character position in the pattern described by FreeDOS help; an asterisk represents a variable tail pattern. The documentation also calls out a compatibility edge case where a short source name and a multi-character question-mark destination do not behave like MS-DOS COMMAND 6.22. This is exactly why a copied pattern from another DOS shell should be tested against the FreeDOS implementation rather than accepted as universal.

Use simple, fixed-position transformations where the mapping can be written down. Before applying a large pattern, create a table with source name, expected destination, and collision status. Ensure every destination is unique and legal on the target filesystem. For a very large or untrusted file set, a small program with a dry-run manifest and explicit collision checks is safer than an opaque wildcard.

Protect against collisions and partial results

A rename operation updates directory metadata; it is not a transaction across an entire wildcard set. A batch of matching files can include names that succeed and names that fail because a destination already exists, a source is missing, or a file is in use. Inspect the utility’s output and the resulting directory rather than assuming all-or-nothing behavior.

Do not write a rename loop that repeatedly changes the same wildcard set without defining its matching behavior. A transformed name might still match a later iteration, or a source pattern may become empty after earlier changes. Use a dedicated staging directory and a one-pass plan when the mapping is complex. Keep the original file list and a reverse mapping outside the directory being changed.

Changing a TXT suffix to BAK is only safe if no target BAK already exists and each resulting base name maps uniquely. If files with both TXT and BAK extensions are present, a rename can fail or leave a mixed state. Inventory both extensions before acting and test the exact FreeDOS command.

The same caution applies to case-only changes. FAT filesystems and DOS APIs generally compare names without treating case as a fully distinct identity, and long-name support adds compatibility details. A command that changes only letter case may be normalized or rejected by a tool or filesystem layer. If capitalization matters for a cross-platform export, perform it with a tool that has an explicit case-rename strategy and verify the stored long and short names afterward.

Use a rehearsal manifest

There is no guarantee that DIR output alone gives a machine-safe mapping. For a small operation, manually build a table from an unmodified copy:

SOURCE          EXPECTED
LOG001.TXT      LOG001.BAK
LOG002.TXT      LOG002.BAK

Then check that every source exists, every destination is free, the source and destination remain on the intended drive, and the recovery copy can be read. Use a disposable copy of the directory to execute the command. Compare the post-run listing with the plan and open representative renamed files. A successful rename should preserve the byte content, but test checksums if the files are important or if other tools may have been active.

For a batch file, keep the command narrowly scoped and check the error result immediately. Do not run subsequent cleanup merely because REN returned to the prompt. FreeDOS batch IF ERRORLEVEL n tests whether the result is greater than or equal to n, so test higher failure values before lower ones if the installed REN defines multiple codes. If the external documentation does not establish a detailed code table, record output and inspect the actual resulting names rather than inventing numeric meanings.

Never remove the only original files in the same batch that renames them. A rename normally preserves the data in place, but a mistaken mapping can make files difficult to identify or overwrite a name an application expects. Preserve a separate copy or disk image until the new naming scheme has passed the consumer application’s test.

Account for 8.3 names and long-filename support

Traditional DOS paths use 8.3 names. Long-filename extensions can expose longer names while retaining a short alias for compatibility. The command documentation’s examples and wildcard behavior should not be generalized to every LFN-aware utility or Windows shell. If a file has a long name, test how REN matches it, what alias remains, whether the destination is accepted, and how another application resolves it.

Use short, unambiguous names when the renamed files must be consumed by software that lacks an LFN API. If the original and new names include spaces or punctuation, verify the command parser’s quote behavior with a sample. Keep exact command syntax as demonstrated by FreeDOS help and use only path forms confirmed in the target. A filename displayed in lowercase is not proof that its on-disk short entry has been transformed into a different case-sensitive identity.

Acceptance criteria

A reliable rename procedure identifies the source directory and volume, lists every intended entry, computes a unique destination for each source, checks for existing destinations, and tests the operation on a copy. After execution, compare the complete result with the manifest, sample-open important files, and verify their content hashes where appropriate. Record the FreeCOM build, LFN provider, and command output.

If a rename fails partway through, stop. Do not rerun the same wildcard blindly, because the source set has changed. Compare the current directory against the saved source/expected table, determine which entries moved, resolve collisions deliberately, then continue from the remaining work. This turns REN from a one-line gamble into a controlled metadata change.

Related:

Sources: