Windows NT Backup and Hard Links

Last reviewed: May 12, 1997
Article ID: Q106166
The information in this article applies to:
  • Microsoft Windows NT operating system version 3.1
  • Microsoft Windows NT Advanced Server version 3.1

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.


Additional query words: prodnt
Keywords : kbother ntfault
Version : 3.1
Platform : WINDOWS


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: May 12, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.