This tagline is false

April 1, 2002

It turns out that Finlay Dobbie’s problems contributing to Darwin may not be Apple’s fault after all. However, minors such as Mr Dobbie can’t enter contracts, such as the involved with Darwin. Bill Bumgarner describes the barriers to allowing minors to contribute, the worst being that the minor’s parents could potentially require his or her contributions to be removed at a later date.

The law itself is well-intentioned, and Apple desire to protect their NDAs is reasonable. It’s unfortunate that they work together to prevent intelligent youth such as Mr Dobbie from participating. (via MWJ) #

Soft links and aliases

Computers generally refer to files in one of two ways. Unix systems refer to files by their name (often called a “pathname”). For example, if some software keeps a list of files I’ve worked with recently, a Unix-like way to do so would be to store a name like “/projects/surfboard/designspec”, which identifies the file “designspec” in the directory “surfboard” in the directory “projects”. (In an actual Unix system, there would be a few more levels, but this is a quick example.)

The other method, used by the Macintosh, involves assigning each file a unique number when it’s created. The user generally never sees this number directly, but applications can create “alias records” for files, which contain this number. We’ll call this number an ID. If the program I described before used IDs, then it would store the file’s number instead of its name.

The difference between names and IDs might not be obvious, but it has to do with stability. IDs are stable: as long as the original file, exists, you can be sure that its ID will always refer to it, even if its name changes. In contrast, the name is only good as long as every element in the name doesn’t change. If I rename the “projects” directory to “products”, then the name “/projects/surfboard/designspec” is no good anymore. Similarly, if I rename a file and then create a new file with the old name, programs that use names would try to use the new file, whereas programs that use IDs would continue working with the old one. Depending on the circumstances, either behavior may be desired. That’s why a good filesystem should allow for both methods to be used. (Then, of course, the system has to know whether users want to refer to a specific file or whatever file happens to have that name when creating references. The details there aren’t important, as long as it isn’t done in a confusing fashion.)

Bill Bumgarner describes one way in which aliases can be annoying:

Every time I upgrade OmniWeb by replacing the existing copy of the application with a new copy, the system [Mac OS X] continues to point to the old version—that it can’t run—that is now in the trash. Once the trash is emptied, the system reverts to IE. The Internet preferences are using an FSRef to point to the web browser. Fine; if you move the web browser app, the system still finds it. However, if I upgrade the app in place (or anywhere else), the system does exactly what I don't want it to.

According to Mr Bumgarner, Mac OS X should be using file names rather than IDs to locate OmniWeb. That is, instead of remembering that OmniWeb’s code is in file #2346081 (say), the system should remember that its code is at “/Applications/OmniWeb”. That solves the upgrade problem, but is problematic because it depends on an unstable reference. If the user needs to move the file containing OmniWeb, or rename them for some reason, then the reference is lost. Mr Bumgarner argues that users should not do these things, but my feeling is that the computer should anticipate modifications to anything users can modify and still work.

You’ll note that I referred to “the file containing OmniWeb” rather than just “OmniWeb”. That’s not simply me being pedantic; the fact is that file names and IDs both refer to files. Applications exist in a different conceptual area, even though it’s common to identify them by the files which contain their computer code. The best way to refer to OmniWeb is to refer to the application itself rather than the name or ID of the file containing its code. That way, it can be moved or replaced by a new version without breaking old references.

Interestingly enough, the classic Mac OS has such a method. Each application is required to have a unique creator ID, and the system is able to use it to refer to applications. That’s how the system implements double-clicking on files: it looks up the creator ID for the file and then tells the application with that creator ID to open the file. (Windows operates by looking at the file name and keeping a list of entries like “open files ending in ‘.txt’ with ‘Notepad’”. Unix requires you to identify the application whenever you open the file.)

Unfortunately, the Mac OS creator ID scheme doesn’t deal well with having multiple versions of the same program available. Furthermore, since looking up a program by creator ID is slower than file ID, most references to applications use the latter. Hence, the problems Mr Bumgarner describes.

As I see it, the solution is for the system to keep an index of all applications. Software should be able to get a stable reference to any specific version of an application or to the “current” version. This would be independent of file name, so users can move application files without causing problems, and independent of file IDs, so users can upgrade without causing problems. #

Postscript: In the same article, Mr Bumgarner describes a problem where Macintosh applications corrupt data by writing over the old file but failing to completely rewrite the new file. He proposes that instead they should write the new data to a new file, and then rename the new file so that it replaces the old file. That way, there are no intermediate states when the file can be completely lost if nothing goes wrong. The error in his argument is the fact that all well-written Macintosh applications already do something like that, only the routine used also resets the file ID. If he’s seeing problems where certain applications aren’t acting correctly, it isn’t Apple’s fault.