Btree directories (Re: Status of HFS+ support)

[flar at allandria.com]

Alexander Viro wrote:
> On Thu, 31 Aug 2000 flar at allandria.com wrote:
>
> > Yes, HFS and HFS+ both have a CNID for each file or directory. It just isn't
> > entirely straightforward to search the catalog by this value, since the key
> > is a combination of parentCNID and name. The CNID is guaranteed to be unique
> > across a filesystem and there are a handful that are reserved for system
> > files/directories such as the root (2) and the "parent of root" (1).
>
> OK. Are they preserved by rename()?

There isn't anything preventing it. A rename() is messy enough because of the
headache of moving around entries in the btree and updating all the implicit
usage of the catalog key which depends on the filename. I don't think the
MacOS actually preserves the CNID on a rename, tho. It's something that I
think would be about the same complexity either way. The only thing you
save by keeping the same CNID is changes to the extents overflow tree,
which is usually empty anyway. (My code doesn't do rename() yet...)

> You don't have to check that directory is not busy in rmdir()/rename().
> Back in 2.2 filesystems either had to do that, or they had to detect
> attempts to read/create in/etc. dead directories. Not much of a save,
> but...

Well, I don't think every filesystem did it properly in 2.2, then. I'm
not entirely sure, but I think HFS wasn't quite as careful as it should
have been about such things. As I recall, the HFS code has wandered around
between different maintainers and is a little messy as a result.

I did finally get a recent source tree for 2.4, and I have to say that the
documenation looks a lot better these days.

	Brad Boyer
	flar at pants.nu


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/