9.6 The Dirty Little Secret of Long Filenames

If you depend on your backup tapes to re-create a crashed hard drive, you need to know that a design flaw in Windows long filenames (LFN) means that your carefully made backup tapes may be nearly useless. This is a deficiency in Windows itself, a flaw in how long filenames and long directory names are implemented. Backup software can do nothing to work around the problem. Image backup is the only way to make a fully reliable backup under Windows.

Read and heed these words: It is impossible to make a reliable file-by-file backup under Windows if the volume uses long filenames or long directory names.

The problem occurs because Windows assigns aliases to long directory names on the fly, as those directories are created, and then uses those generated aliases in the registry. For example, if you install Microsoft Office, it installs to the folder C:\Program Files\Microsoft Office. But when Windows creates the Microsoft Office subfolder in the C:\Program Files folder, it dynamically creates a short alias for the new folder. So, rather than the registry pointing to Word as C:\Program Files\Microsoft Office\Office\Winword.exe, as it appears in a directory listing, the registry might actually point to C:\PROGRA~1\MICROS~3\OFFICE\WINWORD.EXE.

So far, so good. The problem is that Windows nowhere directly links that short directory name to the long directory name. As you use the system, you may create and delete other directories with long names that are assigned similar aliases. If you then back up that volume and subsequently restore it to an empty drive, Windows again creates short aliases on the fly, but without any consistency in assigning short directory name aliases to the same long directory names to which they were originally assigned. A concrete example makes all this clear.

We installed Windows NT 4 to an empty hard disk, using NTFS. It wouldn't have made any difference if we'd used Windows 9X or 2000/XP or the FAT filesystem—all Windows versions have the same flaw. After installing the OS, we installed drivers for a Microsoft keyboard and mouse. Setup for those drivers created the subfolder C:\Program Files\Microsoft Hardware, which Windows assigned the alias C:\PROGRA~1\MICROS~1. We then installed Microsoft Office 2000. Setup installed that in two subfolders, C:\Program Files\microsoft frontpage, which Windows assigned the alias C:\PROGRA~1\MICROS~2, and C:\Program Files\Microsoft Office, which Windows assigned the alias C:\PROGRA~1\MICROS~3.

We then uninstalled the Microsoft keyboard and mouse drivers and deleted the folder that had contained them. This left C:\PROGRA~1\MICROS~2 and C:\PROGRA~1\MICROS~3 on disk, but C:\PROGRA~1\MICROS~1 was no longer present. We did a backup to tape, formatted the hard disk, reinstalled Windows and the backup software, and restored from tape. The restore re-created the folders C:\Program Files\microsoft frontpage and C:\Program Files\Microsoft Office, but with aliases of C:\PROGRA~1\MICROS~1 and C:\PROGRA~1\MICROS~2 respectively. Unfortunately, the registry still thought FrontPage was in C:\PROGRA~1\MICROS~2 and Office in C:\PROGRA~1\MICROS~3, which meant that Windows couldn't find either FrontPage or Office. In other words, Windows broke itself.

You might think that this is a convoluted series of steps that is unlikely to occur in the real world, but in fact this happens all the time. We frequently get messages from readers asking why their systems appear to have been completely corrupted after a disk failure and a restore from tape. This is invariably the reason. If you've ever wondered while uninstalling a program why most uninstallers don't delete the empty folder, now you know the answer. If we hadn't deleted the empty folder in the preceding example, we might have avoided the problem. In particular, note that overly aggressive third-party uninstallers frequently contribute to this problem by deleting empty program folders by default.

In addition to implementing long file and directory names ineptly, Microsoft exacerbates the problem by using default folder names for most of its applications that start with Microsoft. In the preceding example, if Setup had simply named the directories Hardware, FrontPage, and Office (or even MSHardware, MSFrontPage, and MSOffice), there would have been no ambiguity in the aliases assigned to those folders, and the system would have worked properly after the restore. Note, however, that the problem isn't limited to Microsoft program folders. Any software that uses long file and directory names and also uses the registry to locate its program, data, or configuration files is subject to the same problem. To avoid this problem:

• When you install software, always install it to a folder with a short name if Setup offers that option. Most software installs to a long folder name by default, but the default installation location can usually be specified manually. Note that the option to specify the installation location manually may not be visible unless you choose "Advanced Setup Options" or something similar.

• When you create data directories, always use MS-DOS 8.3-compliant directory names. Some software allows you to "point" it toward a directory you have created yourself, but may then add entries to the registry to define that location.

• Never delete a directory that may be subject to this problem, even if you've removed all of the files and subdirectories that the directory contained.

Although you can disable 8.3 filename generation for NTFS volumes, doing so may cause compatibility problems with applications that expect 8.3 filename support. Nor are compatibility problems necessarily limited to older programs. For example, disabling 8.3 filename support may cause problems when burning ISO image files to CD.