Windows NT Backup and Hard Links

This article was previously published under Q106166
This article has been archived. It is offered "as is" and will no longer be updated.
You may experience problems when you use the Backup program to back upfiles that are "hard linked" to each other. Note that hard links canonly be created with POSIX applications; therefore, this will not beof concern for most users.
More information
NTFS supports hard linked files for compliance with the POSIXspecification. Applications other than POSIX applications may nothandle hard linked files correctly in all situations.

Once two files are linked together, you cannot determine which is theoriginal file and which is the copy. This is because both file recordswill point to the same data on disk, and the pointer is a one-waylink. The only information you can get about a linked file is thelink count for that file, and the file index number, which is a 64-bitvalue that uniquely identifies that file on that volume.

When the Backup program reads a file, it can determine that there areother links to that data, but it can't tell what the other filenamesare.

NTBackup keeps a list of all files that it backed up with link countsgreater than one, and it stores the file index number for each one ofthese files. While it is backing up, when it comes across another filethat has a link count greater than one, it searches its list of files,looking for a match of file indices. If it finds one, instead ofwriting the data streams out to the tape drive, it creates a stream oftype BACKUP_LINK and puts information about the filename in thisstream. It does NOT write the contents of the file to the backup tapemore than once.

When BackupWrite comes across a BACKUP_LINK stream when restoring todisk, it will get the information about the other filename from thestream and then it will set up the link. This means that if the firstinstance of a file with hard links that was encountered during thebackup operation is no longer present during the restore operation,the Backup program will fail to restore the subsequent, linkedinstances of the file.


Suppose C:\FILE1.TXT is linked with C:\SUBDIR\FILE2.TXT. If you backup drive C and then reformat and restore the entire drive, there willbe no problems. The Backup program will record the contents ofC:\FILE1.TXT and then record a link pointer for C:\SUBDIR\FILE2.TXT.So on restore, C:\FILE1.TXT will be written out to the disk, andC:\SUBDIRE\FILE2.TXT will be recreated as a link to C:\FILE1.TXT.

If you were to restore only the C:\SUBDIR directory after reformattingdrive C, however, the restore operation would find only the linkinformation when it came to C:\SUBDIR\FILE2.TXT and attempt to createa link to C:\FILE1.TXT which does not exist, because it has not beenrestored. Therefore, the file would not be restored and an error wouldbe registered in the log file for the restore operation.

Article ID: 106166 - Last Review: 10/26/2013 02:07:00 - Revision: 4.0

Microsoft Windows NT Workstation 3.1

  • kbnosurvey kbarchive kbother KB106166