• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Restoring hard links
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Restoring hard links


  • Subject: Re: Restoring hard links
  • From: Mark Day <email@hidden>
  • Date: Mon, 5 May 2008 17:38:41 -0700

On May 5, 2008, at 5:11 PM, Trainor, Chris wrote:

I am trying to figure out the best way of handling hard links when backing up and restoring files. I came across this technote:

http://developer.apple.com/technotes/tn/tn1150.html#HardLinks

which has this interesting statement in it:

“The reason for using a separate link reference number, instead of a catalog node ID, is to allow hard links to be backed up and restored by utilities that are not specifically aware of hard links. As long as they preserve filenames, Finder info, and permissions, then the hard links will be preserved.”

The statement in the tech note was referring to using an implementation, like Mac OS 9, which is unaware of hard links, to do the copy. If you were to preserve the filename, Finder info and permissions *as they are stored on disk*, then you would end up preserving hard links, too.

Since Mac OS 9 knew nothing of hard links, it gives you the raw on- disk Finder info and permissions of the link itself, not the target of the link. For a file having a total of two hard links, Mac OS 9 would see three files -- the two hard link files plus the indirect node file.
This seemed too easy, so I wrote some code that tests restoring the filename, finder info, and permissions for a deleted hard link. This didn’t work. After recreating the file, it was not a hardlink. I ended up with multiple copies of the data.

You're using Mac OS X, which *is* aware of hard links, and resolves them internally. You never see the indirect node file separately. When you access the hard links files, the file system automatically resolves them and uses the content in the indirect node file. So the Finder info and permissions you get is actually coming from the target of the link (the indirect node file), not the link itself.

You would have to use the BSD APIs to get the inode numbers of the files you're interested in, and notice that two or more objects have the same inode number, and conclude that they are hard links to the same file. On the restore side, you'd have to create the file file using one of the paths, then create hard links from the rest of the paths.

Note that some file systems don't actually have hard links, and don't have unique inode numbers. For example, the current implementation of msdosfs (FAT) uses the starting cluster number for the inode number, but empty files (which have no starting cluster) share a single, special inode number. As another example, the current implementation of smbfs (SMB, or CIFFS) computes an inode number based on the file name. You can use getattrlist(2) and look at the ATTR_VOL_CAPABILITIES attribute to see whether a volume supports hard links.

-Mark

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Restoring hard links (From: "Trainor, Chris" <email@hidden>)

  • Prev by Date: Restoring hard links
  • Next by Date: System Information
  • Previous by thread: Restoring hard links
  • Next by thread: System Information
  • Index(es):
    • Date
    • Thread