WinNT: No Rest(ore) for the Wary!

Most IT professionals understand that when it comes to backing up and restoring, it’s not “if” but “when” your hard drive will fail. Strict policies are usually put in place regarding how often backups are done, where the tapes are stored and for how long they will be kept. But, did you know that it is impossible to reliably restore those backups and have the resulting Windows system and applications operate correctly?

To be sure, backup programs can backup and restore your files. But, a serious design flaw exists in Win32 which makes it impossible to ensure that the restored files are in sync with the Windows Registry. This is true even if you backup and restore the Registry at the same time as the files! Unless special measures have been put into place, it would be best to avoid doing any restores on your NT system using your standard tape backup/restore software.

Anatomy of the Design Flaw

Win32, the system API at the heart of Windows 95, 98, and NT, provides support for long file names. The system automatically generates a short 8.3 name for each file. This allows 16-bit MS-DOS programs to access the files.

Win32 does not allow a program to specify both the long and short file names when it creates a file. So, for a program to use long file names, it must allow the system to generate the short one. This includes backup/restore programs. (For more information about how long file names are generated by Windows, please refer to The PC Guide’s File System page)

Short file names are dynamically created every time a long file name is created, whether it be from COPY, XCOPY, RENAME or any other program which creates a new file. When your restore program restores your files using the long file names, as it must in order to preserve them, it is impossible to ensure that the re-generated short file name is exactly the same as the originally generated one!

The problem with this is that there are many entries in the Windows Registry which specify the names and locations of programs and DLLs in the system. If the system cannot find these files via these links in the Registry, it will not operate correctly. Many of the program and DLL paths stored in the Windows Registry use the short path and file name instead of the long path and file name. If such a file’s short name has been generated differently at restore time, it may no longer be found! This could result in crashes, hangs, or any number of other problems that could very easily be interpreted as a software glitch or even a hard disk error, perhaps weeks or months after the restore operation.

Microsoft Has Acknowledged This Problem and has no Solution

Microsoft is aware of this problem and has acknowledged it. But, for some reason, Microsoft is not addressing the issue directly. In Tech Net article Q176014, Microsoft explains that short file names may change after a restore. Affected are NTBACKUP supplied with Windows NT, and all 3rd party backup programs. [Note: This same problem exists in Windows 95 and 98]. The Tech Net article suggests that users use only 8.3 names to avoid this problem, apparently attempting to divert attention away from the real problem by attributing it to the mix of MS-DOS and Win32 systems sharing the same network. There is no mention of the clearly adverse effect of restore on the Win32-based system itself, nor on Win32 applications. Furthermore, users have little or no control over what file names are used by the applications they purchase.

In another Knowledge Base article (ID: Q121007), Microsoft provides information about disabling the creation of 8.3 file names in NTFS partitions – which seems to be a workaround for the problem. Unfortunately, this article also has a note that says “Although disabling 8.3 name creation increases file performance under Windows NT 3.5, some 16-bit applications may not be able to find files and directories with long file names.”

What this seems to indicate is that Microsoft puts the short filenames in the Registry for compatibility with 16-bit programs, and has it enabled by default. Only by essentially ‘hacking’ the Windows Registry can you actually turn this feature off. Note that the Registry entries do not contain both the short and long filenames, only the short one. This Knowledge Base article does not indicate what happens to any existing short filenames in the Registry once this change is made, but it is probably safe to assume that they remain there and the short name may still be required by some applications.

Windows NT – Ready for the Enterprise?

Based upon the information provided by Microsoft themselves, Windows NT is the mission critical 24×7 operating system which cannot be restored from a backup. Maybe one can accept having to rebuild a workstation which does not operate correctly after a restore, but this is completely unacceptable for a server.

It is entirely possible that Microsoft and backup software vendors will attempt to trivialize the impact of this situation, claiming that the chances of any problem occurring are relatively small. The real question to Microsoft for those considering running mission critical applications on Windows NT is: “Can you guarantee that I will not experience a problem with short file names when restoring files to my NT system”. Based upon the referenced Tech Net article, there is no way that either Microsoft or backup vendors can guarantee this without a long list of caveats.

Is There a Solution Available?

Microsoft claims that the ’cause’ of the problem for NTBackup is that it restores the files in alpha-numeric order, and does not restore the short file name. Of course, the reason it does not restore the short file name is because it simply cannot because it is always dynamically created. A possible solution would be to always restore files in the order that their short file names were created, however this also has some potential loopholes, such as ‘gaps’ in the numbering scheme (caused by any number of reasons) which would require the restore software to create bogus file entries to force a particular short name. Unfortunately, the answer isn’t quite that simple for users and software vendors.

It appears that there are several less-than-desireable ‘solutions’ for those needing a reliable backup/restore today. The first is to use a sector-by-sector backup and restore product, however this means taking down the server to restore even individual applications. Another is to reinstall any or all applications that encounter problems rather than simply restore the files. Since data files and directories can also be affected by this (though much less likely), special precautions would also need to be made for directory and file names containing important data.

One possible acceptable solution is to disable short filename creation and ensure you never run 16-bit apps on your NT system. This would require some extensive testing and means short file name creation must be disabled immediately after installing NT. While this may be a good solution for new installations, this would require current NT users is to re-install the entire operating system and all applications to ensure data integrity.

In the final analysis, it appears that the real solution to this problem is for Microsoft to provide an API in Win32 which allows a program to specify the short file name. This would allow a Win32-based backup/restore program to ensure that the short file name is restored exactly as it was when the backup occurred. Why they have not provided this API to this point is rather puzzling.

Be the first to discuss this article!