About | Buy Stuff | Industry Watch | Learning Curve | Products | Search | Twitter
Home » Learning Curve

Fork-U-2

It's not an outrage - is it?

A site visitor sends a URL, a quote, and a question.


'I thought OS X was Unix?'
  - Scott


http://developer.apple.com/documentation
/MacOSX/Conceptual/SystemOverview/FileSystem
/chapter_8_section_5.html


'Files residing on HFS and HFS+ file systems have their Finder attributes stored in a private fork separate from both resource and data forks. These attributes include type and creator codes. Mac OS X maintains these attributes because they enable the Finder to enhance the user's experience. At the same time, however, Apple strongly encourages developers to use file extensions as alternative means for identifying document types. Mac OS X does a very good job of recognizing and handling document extensions. And, as 'Copy and Move Operations' in the chapter 'The Finder' makes clear, if you copy an HFS or HFS+ document to a different platform (including Web servers), file extensions help ensure that the document's type information is preserved.'


While die-hard Mac users think there can be only two forks to any file, the data fork and the resource fork, the APIs available go beyond this, and the fact that forks can be given names and may only be accessed if their names are known raises security concerns considerably: as with Cutler's NTFS, hackers have a nearly fool-proof method of hiding malfeasant code on a remote machine.

Steve Jobs and his NeXT engineers never intended to 'upgrade' MacOS when they came to Cupertino from Redwood City. Work progressed on the 'port' of NeXTSTEP with business being 'as usual' until Steve Jobs in 1998 presented the new OS to a group of selected independent software vendors in San Francisco.

He was booed. What got the audience hostile was the presentation of NeXTSTEP's 'File Viewer' application, the equivalent of KDE's Konqueror, Microsoft's Windows Explorer, and Apple's old Finder.


The NeXTSTEP File Viewer. Obviously this inferior application would have crippled the poor Macintosh.

The vendors were not disappointed in the functionality of File Viewer; they were just being difficult in a typical Mac user fashion. They did not object to the program per se; they objected to there no longer being a program called 'Finder'.

The reaction was so strong that Apple immediately began work on bringing Finder up to NeXTSTEP, a move they will go on regretting until the abortive program is finally abolished, incinerated, castigated, and sent into oblivion - along with the insanely ungreat HFS.


Resource forks would be fine if everyone recognised them, but that's the catch: no one else does. Moreover, OS X is supposed to be POSIX compliant, and you can't have a file system that's not in line with Unix standards. Unix does not admit of forks, so Apple cannot officially recognise them either.

The Cupertino corporation has been walking a very fine line. While letting Finder continue to exist (to please all the die-hards who get so nasty at the intimation it might be scrapped) Apple must continue to respect POSIX and have OS X rely only on POSIX at the ultimate root level.

This of course leads to considerable problems and headaches. Files cannot simply be copied and moved - as Unix does not recognise forks, only the so-called data forks are seen by Unix. Performing file operations from the command line can corrupt an HFS file system. OS X Tiger will supposedly 'correct' this, but in so doing Apple will corrupt the open source code to their FreeBSD Darwin.

Apple understand this, which is why they recommend vendors do not use resource forks, but their stance is ambivalent at best, espousing the use of further forks to assist their paraplegic Finder.

No Unix APIs are aware of resource forks. Unix is very definite in this regard: the only fields of file data recognised are in the so-called 'stat' structure. It is this data which is stored in the file's iblock in the volume ilist.

struct stat {
    dev_t      st_dev;        /* inode's device */
    ino_t      st_ino;        /* inode's number */
    mode_t     st_mode;       /* inode protection mode */
    nlink_t    st_nlink;      /* number of hard links */
    uid_t      st_uid;        /* user ID of the file's owner */
    gid_t      st_gid;        /* group ID of the file's group */
    dev_t      st_rdev;       /* device type */

    struct timespec st_atimespec;    /* time of last access */
    struct timespec st_mtimespec;    /* time of last data modification */
    struct timespec st_ctimespec;    /* time of last file status change */

    off_t      st_size;       /* file size, in bytes */
    int64_t    st_blocks;     /* blocks allocated for file */
    u_int32_t  st_blksize;    /* optimal blocksize for I/O */
    u_int32_t  st_flags;      /* user defined flags for file */
    u_int32_t  st_gen;        /* file generation number */
};

Forget the gobbledegook - it's the names of the fields that are important:

  1. inode's device. You can hop over this one.
  2. inode's number. Well yes. This is self-referential.
  3. inode protection mode. This is the file's actual protection mode.
  4. number of hard links. This is very important.
  5. user ID of the file's owner. Natch.
  6. group ID of the file's group. Vanilla Unix.
  7. device type. Hop over it.

  8. \
  9. the three time fields. Self-explanatory.
  10. /

  11. file size, in bytes. Absolutely.
  12. blocks allocated for file. Hop over it.
  13. optimal block size for I/O. Not important here.
  14. user defined flags for file. These afford more protection.
  15. file generation number. For the superuser only. Hop over it.

There are fifteen fields; that's all there is; the Finder will find fields 3, 5, and 6 (and a couple of the time fields) and only if you beg it to. The Finder will not find the other fields at all.

[Read that last line again: 'The Finder will not find the other fields at all.']

Worse: field 11 means nothing to the Finder - or to anyone running OS X with HFS. This is the size of the data fork, not necessarily the total size of the file. If a file has a resource fork, Finder will report the file as larger - without a whisper of the existence of the resource fork, or how the forks are apportioned.

And when it comes to the Finder's own forks as outlined by Apple above, there won't be a word. Wonder where your disk free space is off to? You can't check. The Finder knows: it's hiding things on your disk but it's not telling.

Want to see where it goes? In action? Do like this:

  1. Make a screen dump. ⇧⌘4. It will appear on your desktop and have the 'PDF' icon.
  2. Drop to a command line at your desktop. Rename the file 'x'. If necessary click on your desktop to get the Finder update. Note that the file still has the 'PDF' icon.
  3. Copy the file to 'y'. 'y' won't have the PDF icon.

Great feeling, isn't it?

Worse still: the Finder can't deal with 4 (hard links). Even HFS has a troubled time trying to accomodate them, and as Rixstep have already shown, often fails in the attempt.

But it's worse still, for the Finder not only cannot report on hard links, it cannot create them for you either, despite the fact this is supposed to be Unix.

[The Finder cannot create symbolic links either, but this only adds insult to injury. The lack of accommodation for hard links is a far deeper, more endemic design weakness in OS X - with no end to the miasma in sight.]

The Finder will not deal with 14 either. These are special user defined flags easily accessible through Unix but totally ignored by the Finder as if they didn't exist.

But they do exist, and some of them are so impervious that a reboot into single user mode is the only way to have them removed.

Unix takes care of them: Unix will edit them and list them. But the Finder doesn't even tell you they exist. Not a word, not a whisper. Nothing.

And yes, what you're thinking is that this is unabashedly outrageous. And you're right: it is. As Scott says, this is not Unix. What it's supposed to be is Unix but it's not even close.

It's an unholy mess.


Steve Jobs and the NeXT engineers would never have gone near such a cockamamie idea if the Apple ISVs had not whined so much about the loss of their precious Finder. A good thing to do at this point would be to assess how many of these ISVs are really supporting OS X today. It's likely one would find the number amazingly small.

Sir Tim Berners-Lee, pictured at right, invented the World Wide Web (and the world's first web browser and web server) on a NeXT computer - without the help of Apple's Finder - and yet he called NeXTSTEP 'the first intuitive point-and-click and folders interface for personal computers'.

But maybe this knighted CERN scientist is wrong and all the Apple ISVs who think things are best with one program and one Finder folder to put it in are right?

In closing, it's most appropriate to quote the blurb Scott sent in by plucking out the perhaps most precious part of it - and it certainly is a mouthful:

'Mac OS X maintains these attributes because they enable the Finder to enhance the user's experience.'

About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.