posted by Scot Hacker on Mon 17th Dec 2001 17:34 UTC
"Alien Filesystems"

In BeOS, file systems (even the native BFS) are handled via plug-ins called add-ons. Download a file system add-on, drop it into place, and you have the immediate capability to read (and often write to) alien file systems. Out of the box, every BeOS machine, whether x86 or PowerPC, can read and write BFS, HFS, HFS+, FAT16, and FAT32 volumes. It can also read (but not write to) ext2fs and NTFS. More obscure file system add-ons can be written by developers and posted for others to use. OS X did a great job of reading a FAT32 volume I stuck in my G4 for a while, but as far as I know, does not handle other file systems as elegantly.

  • Finder
  • Overall, my experience with the OS X Finder has been a wash -- it's both better and worse than the BeOS Tracker. On one hand, I love and use constantly the horizontal scrolling column view. And dynamic resizing of icons is a nice touch. On the other hand, the current Finder does not offer spring-loaded folders, as OS 9 and BeOS do. Be's right-click scroll | navigate mechanism provides the fastest means of navigating, copying, and moving files around in a file system of any I've encountered.

    horiz

    The Finder's horizontal scrolling view is easy to work in and quite elegant, but I still miss spring-loaded folders. Click for larger version.

    But my real complaint with the Finder is that it does a poor job of displaying large quantities of information at once. The default Finder font is too large, and is not user-configurable. However, the 3rd-party Tinker Tool will allow you to change the Finder font. Since Tinker Tool only exposes existing but hidden preferences in the OS, it seems probable that Apple will open this up in the future.

    Which leads to yet another complaint: Compared to BeOS, OS X is downright hostile to long filenames. Sure, OS X now supports filenames up to 255 characters just like BeOS, but displaying long filenames is a pain because of that huge Finder font. Worse, something about the LFN API (I'm not a programmer) makes it very difficult to add LFN support to applications. When it came time to move my MP3 collection from BeOS to OS X via FTP, I found that both Interarchy and Fetch, both of which are Carbonized, truncated the filenames on transfer (I finally solved that one by putting via FTP from the BeOS machine to the OS X box, rather than the other way around). Another day, I was trying to export movies from iMovie with filenames long enough to describe all the video and audio codecs and settings I was using, for the purposes of comparison. The filenames were truncated with garbage characters when viewed in the Finder.

    And neither of the two most popular MP3 encoding tools for OS X -- iTunes and Audion -- give you any control whatsoever over file naming convention. Every MP3 encoder I've tried on any platform offers a dialog giving the user full control over how the MP3 filenames should be constructed. But both of these tools simply spit out songname.mp3. Sure, they're nested in artist and album parent folders, as is also the case on other platforms, but the filenames are next to useless without the parent folders or ID3 tags. Fine for personal use, but rotten for (god forbid) Internet use. Since Apple wants to be the digital hub of my entertainment life, they'll need to recognize that MP3 storage is one of the most common / popular situations where people use very long filenames. OS X apps need to learn to start creating them, and the Finder needs to become more adept at displaying them.

    shortnames

    Short filenames like these are no way to treat your MP3 collection, but neither iTunes nor Audion will generate anything but. Then again, this Finder view is terrible at displaying long filenames. But on the other other hand, being able to preview MP3s and movies directly in the Finder is pretty cool...

    The BeOS Tracker uses a technology called "node monitoring" which lets the Tracker give instant feedback to the user and to other apps. For example, you can see the size of a file increase in the Tracker's info panel in real time as it's being downloaded from the Internet. Fancy node monitoring need not be a priority for Apple, but there's one area where something similar should be considered important: Finder views don't seem to reflect changes in the filesystem until forced to. Try this: Open a Terminal session and a Finder window on the same folder. Type touch foo and watch the Finder. In BeOS, "foo" appears in the Tracker instantaneously. In Windows, the change is reflected quickly. In OS X, the file doesn't show up until I click in that Finder view. This becomes a problem on occasssion when unpacking a tar.gz archive, and the contents don't appear on the desktop until I basically force them to.

  • Sherlock Shmerlock
  • The OS X Find panel is still known as Sherlock, and basically gets the job done, but is a bit too cutesy for my tastes. Cosmetics aside, search capabilities under OS X are not as flexible as they are BeOS, with its virtual database. Attributes aside, Sherlock won't even let me limit my search to specific file types (though the Custom search panel does offer a few generic type categories).

    More problematic, though, is the difference in the way the two systems create indexes. Indexed file systems provide lightning-fast search results. BeOS indexes most attributes and keeps its index up to date automatically, every time a file or attribute is added, modified, or removed. But before you can perform fast searches with Sherlock, you have to let it index your file system, an excruciatingly slow process. One volume on my machine, with around 8,000 MP3s, took almost four hours to index. I'm not kidding.

    Another cool advantage to BeOS queries is that they can be saved for later execution. Drag a query onto the desktop and have instant access to all emails from a certain person, or all MP3s downloaded in the past five days, or all bookmarks related to Mac OS (BeOS bookmark files have keyword attributes), or whatever you like. Queries are always live and real-time, so you always get the freshest data, immediately. You can even "navigate" a query with the right-click | scroll technique mentioned earlier, so you don't even to have to "launch" a query to get at any one of the items in its found set. Sherlock offers nothing similar.

    Sherlock's one advantage* over BeOS queries is that it allows searching on actual file contents, rather than just filename and attributes. BeOS users wanting to search through file contents have to resort either to bash tools or to the 3rd-party Tracker add-on Tracker Grep. Speaking of which, I know that Mac OS 9 had context menus for the Finder which allowed functionality similar to that provided by BeOS Tracker add-ons. Having the functionality of the file manager be essentially infinitely expandable is a powerful feature, and I'm looking forward to seeing that functionality restored in OS X.

    * Sherlock has other advantages if you want to use it to search the Internet, but I'm happy with the mighty Google, and get the impression from talking to other people that Sherlock is used for file finding the vast majority of the time.

    Table of contents
    1. "Out of the Frying Pan..."
    2. "... And Into the Fire..."
    3. "Smells Like Home Cookin"
    4. "A Lot To Like, First Impressions"
    5. "Networking Nirvana"
    6. "CD Burning, Disk Images"
    7. "Applications"
    8. "iMovie, iDVD"
    9. "Browsers and E-Mail"
    10. "Power Editors"
    11. "Community"
    12. "The Bad and The Ugly"
    13. "File System Shoot-Out"
    14. "Application-Binding Policies"
    15. "Alien Filesystems"
    16. "Miscellaneous Moans and Groans"
    17. "All Told, Life Is Good"
    e p (0)    153 Comment(s)

    Related Articles

    posted by Rahul on Sat 11th Oct 2008 01:39
    posted by David Adams on Thu 28th Aug 2008 17:51, submitted by stonyandcher
    posted by Adam S on Tue 26th Aug 2008 13:10, submitted by linuxlinks