muCommander and other complements to Apple Finder


… non-Finder clients (e.g. the Eclipse file browser) …

After experimenting with Eclipse, a review of ten alternatives to Finder (I prefer to think of them as complementary) led me to some interesting applications.


Amongst its many features:

  • files and directories can be effectively moved from one volume to another (copied, then removed from source)
  • move and copy operations can be paused and resumed
    • very useful, although users should understand the implications of an incomplete file not being marked as busy
  • hidden files are shown by default
    • .DS_Store files are shown by default.

From what I can gather…

If you prefer to obscure both classes of hidden file, and the source file is associated with both a .DS_Store file and a ._ dot underscore file then:

  • a copy will omit the hidden files
  • a move MAY LOSE all data/metadata that was previously comprised within the hidden files
    • such losses are not recommended, but are occasionally preferred by some users.

If the source file is on an HFS+ volume, and has Spotlight comments, then

  • a copy or move will preserve the Spotlight comments only if you explicity include the .DS_Store file.

If the source file is on an HFS+ volume, and has a resource fork, then

  • a copy or move to a volume that lacks native support for forks and the like WILL LOSE forked data even if you opt to display both classes of hidden file.

Loss of data is undesirable but still, this is an application that may appeal to users who prefer losses of this type.

For me, the most appealing feature of muCommander is pause and resume of copy and move operations.


If move capability is appealing — and if you prefer to respect Finder’s maintenance of resource forks, Spotlight comments and other extended attributes — then consider Xfolders.

… Full integration of the Finder, thus support of all file operations from and to the Finder …

— so naturally, no pause and resume.


moko me yes! Stepford fingers no

There’s never been an iPod that can stay this clean

What, no fingerprints? I think the fella’s from Stepford. That iPod/iPhone certainly doesn’t go to the same parties that I do.

This is more realistic. I want an OpenMoko handset. With fingerprints just like that.

ZFS, HFS+, resource forks, CIFS, NTFS ADS data streams, VFS, VFSFT_XVATTR, extended attributes


I’m necessarily thinking about ZFS and Mac OS X 10.5 before Apple’s Worlwide Developers Conference.

(10.5 aside: I’m dreaming of MacFUSE + ZFS + MacFusion for Mac OS X 10.4.)

Amongst the ZFS-related comments under Sun’s New Modular Blade Servers:

Case-insensitive ZFS support was fast-tracked and approved May 9. It’s not currently integrated into opensolaris, so it would appear that this is all about Apple and replacing HFS/HFS+.


If case-insensitive is about OSX then why does the mail folder on that talk about being for CIFS?

Consider two sets of information:

1) ZFS case-insensitive support — PSARC 2007/244 (Approved FastTrack) — onepager

This fast-track was spun off of the CIFS Service (PSARC 2006/715) case along with:

Although each of these changes are part of the bigger picture…

2) VFS Feature Registration and ACL on Create case materials

… The challenge is to support new, optional file system features without requiring all file systems (especially unbundled file systems) to support or even be aware of the new features.

The solution is to provide a VFS Feature Registration mechanism. At mount time, a file system can register the set of features that it supports. A set of interfaces to register and query features is provided. The feature information is stored in the vfs which makes it file system independent. Savvy callers can query the features of a file system to make informed decisions on which behavior to request. Finally, the feature registration mechanism allows decisions to be made at the VOP/fop layer so that requests for features not supported by the mounted file system can be rejected. …


Several VFS Features will be defined for the initial implementation.

… The following are additional features that will be fully described in subsequent fast-tracks.
DISCLAIMER: The names below are subject to change.

  • VFSFT_XVATTR – File system (FS) supports extensible vattr structure
  • VFSFT_CASEINSENSITIVE – FS supports case insensitive behavior
  • VFSFT_NOCASESENSITIVE – FS does not support case-sensitive behavior
  • VFSFT_DIRENTFLAGS – FS supports flags on directory entries


“VFS features” are intended to represent optional features that mounted file systems may support. Examples of optional features are listed in the “VFS FEATURES” section (above). Not all file system types support all features. (Initially, only ZFS will support these features.) …


It’s not all about CIFS or HFS+ or ZFS or OpenSolaris or Sun.

It is partially about optional features that mounted file systems may support.

  • CIFS supports extended attributes — non-file system attributes
  • other protocols/systems that support extended attributes (or multiple forks or multiple/alternate data streams (ADS)) include AFP, HFS, HFS+ and NTFS.

As many people are unaware of resource forks and the like in systems other than HFS+ I’ll offer three examples:

ZFS is already fork-capable

According to that Wikipedia article: in a Solaris context,

  • file forks are known as extended attributes

Christopher R. Hertel describes other contexts — CIFS, Samba and Windows — in which:

  • extended attributes (EAs) and alternate streams are similar, but different.

Last but not least, I am advised that on Solaris:

  • it is no problem to have a raw device in a zpool

and if the same will be true for Mac OS X 10.5 and ZFS, then I guess it will be up to us (Mac uses) to do whatever we wish with raw devices within a zpool.


The communities’ diverse interpretations of technologies, layers and expressions will inevitably lead to confusion at some point. Be prepared!

WWDC should help to clarify many misconceptions.

concurrent collaborative authoring and editing with a focus on ODF

My recent thoughts on this subject were offered to the MacFusion-devel group.

Focusing for a moment on Thoughtslinger,

  • a preference for Java is explained in the FAQ, and they don’t (or didn’t) rule out future Mac and Linux builds
  • comments at the SolidOffice blog note the absence of styles but acknowledge the fact that the technology is beta.

Defocusing from Thoughtslinger, thinking beyond styles, I wonder:

  • how will collaborative concurrent authoring environments cope with sound and vision within ODF documents?

These thoughts are relevant to my co-management of an Access Grid node at Freeman Centre.

I encourage the addition of sound and vision to NeoOffice and for Mac OS X but understand that QuickTime integration is, for the Aqua port of OOo, further down the timeline (I raised the question at the Mac OS X Port meeting on 25th May, their response came just after the log was committed).

Update, 3rd June: I’m about to make my first foray into Coventi. Whilst it promises to be great for collaboration, I’m not sure whether it allows concurrent edits to a page. More on Coventi to follow…