As mentioned in the Ars Technica article linked above this file system compression is not backwards compatible. Viewing a file compressed via HFS+ Compression in an earlier version of Mac OS X will just show a zero-sized file: the data is “hidden” in the resource fork, so HFS+ Compressed files viewed in 10.5 and below appear to be zero sized, and there’s no (easy) way to access the compressed data. This lack of backwards compatibility may be the reason that Apple haven’t exposed this feature to users; they have given no simple way to simply tell the system to compress part of the filesystem.

There is one way to compress files in the filesystem, using ditto. In Snow Leopard, on a HFS+ disk, this command would copy the folder ~/Documents/Archive to ~/Documents/Archive_compressed, while compressing the data:

ditto --hfsCompression ~/Documents/Archive ~/Documents/Archive_compressed

The Archive_compressed folder is still “live”, it can be browsed and files will look exactly the same, but in the background the system will be decompressing them whenever you open them.

Unfortunately this compression system uses a private API, so there isn’t an easy way for anyone to develop an application to let users get to this functionality easily. Fortunately, someone has managed to make a tool that does that. As detailed in this Macrumors thread, bkirch managed to reverse engineer the system calls ditto was making, and has created afsctool. This tool lets you specify different folders to compress, the settings used, and also lets you view details about which files have been compressed, and interestingly how much space has been saved by the compression.

There’s extra-overhead incurred in the background compression and decompression of these files, so you wouldn’t want to use compression exclusively across your entire system (and with the default settings only small files are compressed anyway) but for infrequently used files it’s definitely interesting. When I tested the compression level achievable with a number of 30-40GB folders of general files with a bit of a design tilt (including a fair number jpegs which won’t compress much further) I’ve seen reductions in disk space usage of around 30%. That’s not bad. Bear in mind that if you’re testing this with your own files, the Finder will always show the uncompressed sizes when you do a “Get Info” on a folder. The best option is to use afsctool with the -v switch, which handily shows the exact percentage saving the compression is making, the command is of the form:

afsctool -v ~/Documents/Archive_compressed

It would be nice if Apple gave more direct access to this feature, but in the meantime afsctool is useful, and it may be that this is simply a stop-gap feature until Apple’s new filesystem hits the streets.

At the same time Apple are after a File System Engineer. Doesn’t seem like a coincidence.

So presumably we’re not going to get a modern filesystem for a while and I have a horrible feeling that what we’ll get will in fact be HFS+ with some extra features gaffer-taped on (“What do you mean it’s not as good as ZFS, it’s got snapshots, that’s like ZFS, right?”).

I don’t know if there’s any possibility of carrying on the project without Apple’s backing, I get the feeling that this set of events (including the terrible communications from Apple) has pushed a lot of the kind of people who could support a community backed ZFS towards alternate operating systems (FreeBSD and OpenSolaris both supporting ZFS).

The one obvious omission is an external interconnect that gave a few more options for attaching external storage. An eSATA or SAS connector would have vastly expanded the options for attaching low to mid-level RAID and JBOD units, and would have really finished it off from my point of view. As it is there is Firewire 800 still and Apple are selling a reasonable looking Promise SmartStor DS4600 alongside the mini, that looks reasonable. There’s also the Drobo and DroboPro that come with Firewire and USB connections, I just can’t help but think they’ve slightly missed an opportunity to open up the storage options a little.

In general though I’m probably being a little picky about the lack of SAS/eSATA. This is a great new addition to the Mac lineup and makes OS X Server even more accessible for smaller businesses where it can be a first class solution for mail, file sharing, calendaring and the whole raft of OS X Server’s tricks. It’s also very cost effective for schools and other organisations with predominantly Windows backends who don’t need specific services but would like to manage their Mac clients with an Open Directory deployment. We’ve already been asked by one client to supply one, and I can see them being the first of many.

Now all we need is for about 50% of the races to be held at Interlagos, best race of the season by far. The rest can be split between Spa and Montreal, possibly Monaco for the tradition.

One minor issue with the new system is that the shiny new interface for managing services (and for restoring some people’s old favourite services such as the “Send File to Bluetooth Device”) is hidden inside the Keyboard section of System Preferences, beneath the Keyboard Shortcuts tab.

There’s a great article about the new Services system written by Rob Griffiths over at Macworld.com.

That’s before you even get to the reporting features of ARD.

Of course before you can use it on the client Macs it needs turning on and while that’s easy to do via System Preferences, if you want to activate it across hundreds of Macs at once then that’s not a fun prospect. There is a Terminal command that can turn ARD on (kickstart), which would be really easy to send via the “Send UNIX Command” option in ARD. Ho hum.

You can turn ARD on in your client image before deployment, but that doesn’t help if you aren’t running a generic image on all of your Macs. Unfortunately there isn’t a preference setting in Open Directory that you can use to push a “turn ARD on” setting out to clients bound to the directory. You can work around that however and the easiest way is just to add the kickstart command to your login scripts. For instance adding this command would turn on ARD and give all access privs to a local user called macadmin (the command is entered all on one line but is wrapped here):

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart
 -activate -configure -access -on -users macadmin -privs -all -restart -agent -menu

You can be a bit neater with Leopard, which creates a file in /Library/Preferences called com.apple.RemoteManagement.launchd (containing the cryptic text “enabled”) when ARD is turned on, and removes it when it is turned off. As a result you can very easily check for the existence of that file and only run the kickstart command when ARD is deactivated by using:

if [ ! -e /Library/Preferences/com.apple.RemoteManagement.launchd ]; then
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart 
-activate -configure -access -on -users macadmin -privs -all -restart -agent -menu
fi

That file doesn’t seem to be created in Snow Leopard though, it’s probably simple enough to do something based upon ps auxc | grep ARD with some checking to see if the ARDAgent is running or not, but I’ve not looked into that yet as large scale Snow Leopard deployments are still a little way off and I have a feeling that the ARDAgent may actually restart when a user logs in, hence making that option less reliable. It would need some testing, but to be honest there’s not a big problem with running the kickstart command if ARD is already turned on, so testing for the setting is more of a quest for neatness, and possibly slightly trimming login time, rather than any real necessity.

Of course this does mean that someone has to login to the Macs before ARD will be activated but this approach should ensure that the vast majority of your Macs have ARD turned on without too much walking between machines.