Microsoft KB Archive/106166
Article ID: 106166
Article Last Modified on 11/1/2006
- Microsoft Windows NT Advanced Server 3.1
- Microsoft Windows NT Workstation 3.1
This article was previously published under Q106166
You may experience problems when you use the Backup program to back up files that are "hard linked" to each other. Note that hard links can only be created with POSIX applications; therefore, this will not be of concern for most users.
NTFS supports hard linked files for compliance with the POSIX specification. Applications other than POSIX applications may not handle hard linked files correctly in all situations.
Once two files are linked together, you cannot determine which is the original file and which is the copy. This is because both file records will point to the same data on disk, and the pointer is a one-way link. The only information you can get about a linked file is the link count for that file, and the file index number, which is a 64-bit value that uniquely identifies that file on that volume.
When the Backup program reads a file, it can determine that there are other links to that data, but it can't tell what the other filenames are.
NTBackup keeps a list of all files that it backed up with link counts greater than one, and it stores the file index number for each one of these files. While it is backing up, when it comes across another file that 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 of writing the data streams out to the tape drive, it creates a stream of type BACKUP_LINK and puts information about the filename in this stream. It does NOT write the contents of the file to the backup tape more than once.
When BackupWrite comes across a BACKUP_LINK stream when restoring to disk, it will get the information about the other filename from the stream and then it will set up the link. This means that if the first instance of a file with hard links that was encountered during the backup operation is no longer present during the restore operation, the Backup program will fail to restore the subsequent, linked instances of the file.
Suppose C:\FILE1.TXT is linked with C:\SUBDIR\FILE2.TXT. If you back up drive C and then reformat and restore the entire drive, there will be no problems. The Backup program will record the contents of C:\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, and C:\SUBDIRE\FILE2.TXT will be recreated as a link to C:\FILE1.TXT.
If you were to restore only the C:\SUBDIR directory after reformatting drive C, however, the restore operation would find only the link information when it came to C:\SUBDIR\FILE2.TXT and attempt to create a link to C:\FILE1.TXT which does not exist, because it has not been restored. Therefore, the file would not be restored and an error would be registered in the log file for the restore operation.
Additional query words: prodnt
Keywords: kbother KB106166