Fixing DOSLFN Long Filename Problems on FreeDOS

DOSLFN adds long filename support to FreeDOS — but loading it doesn’t make every DOS program suddenly understand long names, which is the most common source of confusion when troubleshooting this.

Step 1: confirm DOSLFN is actually loaded

LOADED /C:DOSLFN

Or check CONFIG.SYS/AUTOEXEC.BAT directly for the line loading DOSLFN.COM or DOSLFN.EXE.

Step 2: understand what DOSLFN does and doesn’t do

DOSLFN intercepts DOS filesystem calls to translate between long names and their underlying 8.3 short-name equivalents — but it only works for programs that make their file-access calls through the standard DOS API that DOSLFN can intercept. A program bypassing that API to touch the disk directly, or one with hardcoded assumptions about 8.3-only filenames, will never see long names regardless of DOSLFN’s presence.

Step 3: check whether the specific failing program is DOS-API-compliant

Most well-behaved DOS programs, and virtually all FreeDOS utilities, use the standard API and work correctly with DOSLFN. Older or more aggressively optimized commercial DOS software — especially disk utilities and some games with custom low-level disk access — are the most common exceptions.

Step 4: verify the underlying filesystem actually supports long names

DOSLFN requires a FAT filesystem with VFAT-style long
filename entries already present — check that the
partition was actually formatted/used in a way that
supports this.

A pure FAT12/16 volume with no VFAT long-name directory entries at all has nothing for DOSLFN to translate.

Step 5: check load order in CONFIG.SYS/AUTOEXEC.BAT

DEVICE=C:\FREEDOS\BIN\DOSLFN.COM

DOSLFN needs to load early enough to intercept calls from programs started afterward — a program launched from AUTOEXEC.BAT before DOSLFN’s own loading line runs without long-filename support for that specific session.

Step 6: use the 8.3 short name as a reliable fallback

DIR /X

/X shows both the long name and its underlying 8.3 short-name alias — for a program that genuinely can’t work with DOSLFN, referencing files by their short name directly sidesteps the problem entirely rather than fighting it.

Step 7: check for a DOSLFN version mismatch or known compatibility note

Check the DOSLFN documentation/changelog for any noted incompatibilities with the specific program giving trouble — some interactions between LFN drivers and specific commercial software are documented, known limitations rather than local misconfiguration.

Why “loaded but not working for this one program” is usually correct behavior, not a bug

DOSLFN’s translation only ever covers programs going through the interfaces it can actually intercept — a program bypassing those interfaces was never going to see long filenames no matter how DOSLFN itself is configured. Confirming which category a failing program falls into (Step 3) is what distinguishes a genuine configuration problem from an inherent limitation of the specific software involved.

What DOSLFN actually costs you, and when that matters

Because DOSLFN runs as a resident driver intercepting DOS filesystem calls continuously, it holds a small amount of memory for as long as it’s loaded — modest compared to a full memory manager, but not free, and worth factoring in on a machine already tight on conventional memory after loading several other TSRs and device drivers. If DOSLFN specifically is what pushes a demanding application over a conventional-memory limit, loading it high via DEVICEHIGH= into upper memory (when UMB space is available) recovers that cost without giving up long-filename support entirely.

When a narrower, program-specific LFN tool is the better fit

DOSLFN is a general-purpose, system-wide solution, but it isn’t the only long-filename tool in the FreeDOS ecosystem — the broader LFN Tools project bundles several more narrowly-scoped utilities for specific long-filename tasks. If DOSLFN’s system-wide interception is more than a specific workflow actually needs, checking whether a narrower, purpose-built tool covers that one task is worth doing before assuming DOSLFN itself needs to be reconfigured further.

Related:

Sources: