Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Learning Curve » Developers Workshop » One Year with Lion

One Year with Lion (4)

Year Two might be better.

Get It

Try It

CUPERTINO (Rixstep) — Apple's OS X 10.7 Lion was introduced one year ago next week. It's been a bumpy ride. Lion's successor is due out within days. Let's hope for something a bit better.

'.HFS+ Private Directory Data\15'

It was quite a job force-fitting HFS to the Unix model. It took a lot of work and the fit isn't perfect. The brave Apple engineer tasked with the job had to find ways around things as much as he could.

The basic snag was of course the Unix hard link. Unix files don't have names per se - their directories do. A Unix directory is simply a 'value-key' pair of file indexes (inodes) and file names. The file names are found nowhere else.

So it stands to reason - and the eternal benefit to Unix gurus - that you can have the same file in another location. Not a copy of the file - the very same file itself.

The usefulness of so-called hard links is readily apparent in any of the Unix 'bin' directories on OS X. Programs can easily determine the file name used to invoke them and can then branch on functionality thereafter.

And most file systems, although sometimes radically different (and inferior) to the Unix model, can in a pinch adapt this idea. All that is save Apple's HFS.

And why? Because Apple like to lead a user back from a CNID to an actual file name. Apple's HFS wants to identify files only by their file index. Apple can then tell a user that a file name has changed and still find the file (because they never lost it).

But the Unix system allows for multiple files (file paths) for the same physical entity on disk. Clearly Apple's HFS would be lost if forced into such a scenario. What to do?

It's been outlined and explained thoroughly elsewhere at this site, but briefly: Apple OS X installations using HFS+ put a secret directory in the file system at root. The name of this directory has changed over time but the base part of it is 'HFS+ Private Data'. The additional characters they use are there to make it difficult for you to access things.

Rixstep's GDE has always got in. But now with Lion, Apple upped the game again.

Files listed with an inode of 0 (zero) are slated for deletion and are to be ignored by file system tools. More: the zero inode is never used in that context and so cannot possibly lead anywhere. Finally: any number of files slated for deletion can have the same zero inode, so the prospects become even more futile.

Yet Apple today brandish the zero inode on any number of hidden files and directories at system root.

And those files and directories are obviously being used. So how do they do it?

In a word: they 'root kit' their own system.

/*
 * Look up an HFS object by ID.
 * * * *
 */
int
hfs_vget(struct hfsmount *hfsmp, cnid_t cnid, struct vnode **vpp, int skiplock, int allow_deleted)
{
    /* * */

    /* Check for cnids that should't be exported. */
    if ((cnid < kHFSFirstUserCatalogNodeID) &&
        (cnid != kHFSRootFolderID && cnid != kHFSRootParentID)) {
        return (ENOENT);
    }
    /* Don't export our private directories. */
    if (cnid == hfsmp->hfs_private_desc[FILE_HARDLINKS].cd_cnid ||
        cnid == hfsmp->hfs_private_desc[DIR_HARDLINKS].cd_cnid) {
        return (ENOENT);
    }

    /* * */
}

Of course the data is still available - but you have to attach your Lion hard drive from a boot of another version of OS X. Then it's all there in its full glory.

'FileMerge'

Sometimes it's hard to get the code right the first time around. Companies with no time constraints should never run into this. But the stress of major commercial operations can lead to loose ends and egregious bloopers.

But this only in startups - in new code. The patience with OS X 10.0 and 10.1 was manifest - say what you want, but you believed they'd sooner or later get it right.

It's quite another matter when they take good code that already exists - and has for tens of years - and in some inexplicable fashion and for some unknown reason manage to totally fuck it up and worse still: get it out the door and past the QC crowd.

But that's what Apple did with their otherwise eminently indispensable 'FileMerge' that ships with their Xcode developer tools.

One simply can't understand how a corporation of Apple's caliber can let something like this happen.

One | Two | Three | Four | Five | Six