Windows NT Backup and Hard Links (106166)
The information in this article applies to:
- Microsoft Windows NT 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.
MORE INFORMATION
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.
Example
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.
Modification Type: | Major | Last Reviewed: | 10/29/2003 |
---|
Keywords: | kbother KB106166 |
---|
|