On Oct 4, 2008, at 12:41 AM, Michael Smith < email@hidden> wrote: On Oct 2, 2008, at 5:50 PM, Chris Idou wrote: I don't see why this sort of stuff should be considered some kind of private detail of Time Machine. Especially since it is in the kernel, and the API is a public one. The behavior of the API is undocumented, but it shouldn't be. The behavior of all public APIs should be fully documented and available to all.
|
It's not a "private detail"; it's being discussed here on an open list.
The point being made is that it's not a good thing to use for anything else (and it's entirely debatable whether it was a good idea for what it's being used for right now), and you should stay away from it.
Not because it would give you some sort of competitive leg-up that you're not supposed to have, but for your (and everyone else's) own good.
I've been quiet in this thread so far, even though it is one of my religious issues...
Hi, I'm the one who killed hard links for directories in BSD derived UNIX systems while working on FreeBSD in 1992, which was later picked up by the other BSDs and then the CSRG at UCB for the BSD 4.4 distribution.
Hi again. I'm also the one who killed hard links for directories at Novell/USG, aka USL, in 1994, with that change being picked up in SVR4 derived systems, like UnixWare, Solaris, etc..
It's just too darn useful to be able to ask a directory for its parent and get one answer, and to not have to deal with the possibility of Hamiltonian cycles in path lookups or crash recovery.
The current very restricted support for hard links to directories in HFS is an implementation detail of Time Machine.
If you use them for your own software, expect them to go read-only *the instant* that implementation detail changes, and to break completely the next possible release where the already created Time Machine archives can be reasonably expected to have been migrated.
You *really* do not want to build code that depends on this implementation detail.
-- Terry |