Re: Restoring hard links
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