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

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: Every time I upgrade OmniWeb by replacing the existing copy of the application with a new copy, the system 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. By default, a number of drag and drop operations [in X and 9] create aliases. If you don't fully grok aliases as most of the 'rest of us' don't, this often means that you aren't actually copying the data when you thought you were. Then you go and delete the original. Now the alias is broken and you can't find the original because it is gone. 2 years of writing for a book gone. Sucks to be you. Say you are working with a really large image file on a system with very little disk space. You save. App merrily starts writing over the old file in the filesystem. Disk runs out of space. Old data gone, new data corrupt. Oops. (Obviously, with the new multi-bazillion byte drives that ship with computers, this is not nearly as much of an issue -- however, i was nailed by this numerous times when I was suffering with a really full hard drive.) Aliases-- really, filesystem references-- often follow the wrong thing; many, many times I have had to walk one of the 'rest of us' through the fact that an alias now points at something in the trash-- be it an app or document. There are more, but my train ride is ending... 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... 9:42:02 AM