9.5 The Dirty Little Secret of Long Filenames
If you depend on your backup tapes to recreate 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.
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 this all clear.
We installed Windows NT 4 to an empty hard disk. It wouldn't have made any difference if we'd used Windows 9X or 2000/XP 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 recreated 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.
In addition to implementing long file and directory names ineptly, Microsoft exacerbates the problem by using default folder names for most of their applications that start with Microsoft. In the example above, 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: