|Tuesday, March 26, 2002|
Search Google is a little chunk of freeware that adds a 'Search Google' menu item to OS X's service menu. Select some text, shift-cmd-G, up pops the Google results.
2:36:10 PM pontificate
Steve Zellers posted a rant about file system fragility in OS X (he called it a rant, not me). While the rant makes a number of very good points and, certainly, the current behavior in OS X is far from ideal, my experiences with the OS 9 and prior filesystem has been quite a bit different.
Steve says: A big loser in Mac OS X is the file system fragility problem. In Mac OS 9 applications always kept aliases to applications, or used the desktop database to search for the information they wanted. Now, people hardcode paths to things and expect that the view of the filesystem as shipped by Apple is going to be consistent. Apple applications do this too.
This is a problem because it isn't our computer, its our users. And our user should be able to set it up any damn way they want.
No, user's should be able to do whatever they bloody well please under their user account. Mac OS X is a multi-user system out of the box. Every Mac OS X box can easily support many users using the box via different accounts and logins. If my wife logs into my OS X box or into my sister's OS X box-- which she does-- it makes life loads easier if Applications are where she expects them to be and if her account has all of the appropriate defaults.
I wrote a previous rant on the subject, so I won't go into detail here...
Unix people will defend this behavior saying that its correct and that the Mac way is an aberration - that they meant for a new file to be created. Perhaps, but I would submit its because they never had a system that cared about the integrety of their data before.
When saving a file, the best way to ensure data integrity is to save the data as an atomic operation [in filesystems that don't otherwise offer an automatic mechanism for doing so]. That is, save a completely new copy of the file, verify that the save actually worked, rename the old to old-backup, rename the new copy to the original file name. TextEdit and most other Cocoa applications do some variant of these steps; backup, save, rename.
Unix people do not view the file system as the most important thing. Data integrity has always been of the utmost importance. It is one of the reasons while file permissions exist in the first place. It prevents the user-- or a nasty program that has infiltrated the user's account-- from destroying the system, a system that is very likely used by multiple people.
That the applications don't track the filename as it is changed in the Finder is most assuredly a bug (as is all of the behaviors Steve documents that result from that).
Finally, aliases suck. Or, at least, the Macintosh implementation of aliases do. I cannot tell you the number of hours I have spent explaining aliases and undoing alias stupidity on various random computers owned by family members. These folks represent the 'rest of us' that Apple has always claimed the Macintosh is built for and, guess, what the 'rest of us' do not understand aliases.
Some of the more fun behaviors of aliases and the Classic filesystem:
This is not to say that the current behavior in OS X is ideal. It isn't; there is a lot of room for improvement and, it appears, that Apple is both aware of and pursuing said improvements.
My point is that the behavior of OS 9 was far from ideal, as well. I have a seen a lot of folks coming from the OS9 world complain that X sucks because it doesn't work like 9.
All in all, the idea of aliases/filesystem references. The idea that an application can have a reference to a file that follows the file around the disk is extremely powerful and useful. However, there has yet to be an implementation that wasn't seriously problematic.
Familiarity taints perspective.
The Mac community has suffered a lot from that; Cocoa programmers berating Carbon programmers and vice-versa, Classic folks berating Unix folks and vice-versa, Metadata vs. no-metadata, etc...