The better solution is to just set the size of each file you add to the archive. That way you can keep Zip64 compatibility and Mac compatibility.

I owe this solution to the excellent SharpZipLib forum, which covered this problem a while ago, but which I missed when I wrote the earlier blog.

Here’s an updated version of the zip tool in C# that makes Macs happy without annoying anyone else:

using System;
using System.IO;
using ICSharpCode.SharpZipLib.Core;
using ICSharpCode.SharpZipLib.Zip;


public class ZipTool
{
    public static void Main(string[] args)
    {
        if (args.Length != 2) {
            Console.WriteLine("Usage: ziptool <input file> <output file>");
            return;
        }

        using (ZipOutputStream zipout = new ZipOutputStream(File.Create(args[1]))) {
            byte[] buffer = new byte[4096];
            string filename = args[0];

            zipout.SetLevel(9);

            //  Set the size before adding it to the archive, to make your
            //  Mac-loving hippy friends happy.
            ZipEntry entry = new ZipEntry(Path.GetFileName(filename));
            FileInfo info = new FileInfo(filename);
            entry.DateTime = info.LastWriteTime;
            entry.Size = info.Length;
            zipout.PutNextEntry(entry);

            using (FileStream fs = File.OpenRead(filename)) {
                int sourceBytes;
                do {
                    sourceBytes = fs.Read(buffer, 0, buffer.Length);
                    zipout.Write(buffer, 0, sourceBytes);
                } while (sourceBytes > 0);
            }

            zipout.Finish();
            zipout.Close();
        }
    }
}

Extra TL;DR When creating zip archives with SharpZipLib make sure you set the file size, disabling Zip64 is neither here nor there.

A project I am working on sources a zip archive from a Web service, extracts the XML file from the zip and then does silly amounts of processing of the data in that XML to produce a new XML file which is returned to the user.

But the sourced zip archive cannot be opened using Python’s zipfile module, and when saved on a Mac the archive cannot be opened using the built-in Archive Utility.app. If one double-clicks the zip, Archive Utility.app just compresses it again and sticks “.cpgz” on the end of the file name.

Fortunately the developer of the Web service is very helpful (the service is written in C# and runs on Windows) and although he didn’t know why Macs were having problems (the built-in Windows zip tool can handle the archive fine) he showed me the code that creates the zip file.

Turns out they were using SharpZipLib, an open-source library for C#. And it turns out SharpZipLib creates archives using Zip64 format by default.

The fix was to disable Zip64 when creating the archive. Here’s a trivial command-line program that creates a zip and disables Zip64 for Mac compatibility:

using System;
using System.IO;
using ICSharpCode.SharpZipLib.Core;
using ICSharpCode.SharpZipLib.Zip;


public class ZipTool
{
    public static void Main(string[] args)
    {
        if (args.Length != 2) {
            Console.WriteLine("Usage: ziptool <input file> <output file>");
            return;
        }

        using (ZipOutputStream zipout = new ZipOutputStream(File.Create(args[1]))) {
            byte[] buffer = new byte[4096];
            string filename = args[0];

            zipout.SetLevel(9);

            // Disable Zip64 for Mac compatibility
            zipout.UseZip64 = UseZip64.Off;

            ZipEntry entry = new ZipEntry(Path.GetFileName(filename));            
            entry.DateTime = File.GetLastWriteTime(filename);
            zipout.PutNextEntry(entry);

            using (FileStream fs = File.OpenRead(filename)) {
                int sourceBytes;
                do {
                    sourceBytes = fs.Read(buffer, 0, buffer.Length);
                    zipout.Write(buffer, 0, sourceBytes);
                } while (sourceBytes > 0);
            }

            zipout.Finish();
            zipout.Close();
        }
    }
}

The disadvantage of disabling Zip64 is you cannot create archives larger than 4 gigabytes, nor can you add files larger than 4 gigabytes before compression.

The advantage of disabling Zip64 is you make me and all my Mac-using hippy friends happy. In concrete terms, disabling Zip64 makes it more likely I will buy you a drink.

Hi Gaston!

Also many thanks to the maintainer of NAnt in MacPorts, who responded to my bug report and pushed an updated NAnt to MacPorts extremely quickly. Although SharpZipLib doesn’t officially support Mono, it builds without a hitch using the “build-net-2.0″ target if you hack the SharpZlib.build NAnt script like so:

<target name="build-mono-2.0" >
    <call target="build-net-2.0" />
    <!--<fail message="Dont know how to build for Mono 2.0." />-->
</target>

Also thanks to the Mono project! Saved me having to fire up a Windows virtual machine to figure out this problem.

Note how none of the files in that list has a name containing the text “david buxton”.

Perhaps deleting the Spotlight index would fix things. Meh.

Anyway, for the first few chapters the book leads you through a number of small applications, each exercise starting a new project. Then in the later chapters Hillegass has you adding features to a single project called RaiseMan.

It strikes me that the next edition of the book should introduce using version control to track development.

Many chapters in the book end with challenges that go off on a tangent, getting you to implement alternate approaches to the exercises covered in that chapter. But then the subsequent chapter will expect you to work with the version of the RaiseMan application as it stood before the previous chapter’s programming challenge.

This is a natural fit for revision control (aka VCS). The book would teach you how to tag “release” versions of your code. It would teach you how to create an experimental feature branch for the chapter-end challenges, and then how to resume development from the last “release” version for the next chapter’s main exercises.

This is particularly relevant now that Xcode 4 includes Git integration. Of course there is no reason one can’t employ a suitable version control system with the current (third) edition of the book; I just think it makes a lot of sense to get younglings used to this workflow while teaching them all the other stuff about lightsabres and the Force while you’re at it.

You will up-vote this on Reddit / Hacker News (waves hand like her Imperial majesty).

Why did Apple allow the new App Store application to ignore the human interface guidelines? It isn’t like the toolbar is doing anything radically different to other information browsers, nothing that might warrant exploring new interface ideas.

It just looks odd, an arbitrary inconsistency that would be simple to correct.

Most of this was culled from a thread on the minidlna forum.

First install each of the following ports. The command for each would be something like sudo port install libiconv.

• libiconv
• sqlite3
• jpeg
• libexif
• libid3tag
• libogg
• libvorbis
• flac
• ffmpeg

Then check out the Mac branch of the current minidlna source from the CVS repository.

cvs -d:pserver:anonymous@minidlna.cvs.sourceforge.net:/cvsroot/minidlna checkout -r osx_port minidlna
cd minidlna

The current build script appears to miss out pulling in libiconv so I had to edit configure.ac, inserting a line to bring in libiconv.

AC_CHECK_LIB([iconv], [main],, AC_MSG_ERROR(Cannot find required library iconv.))

Now the build will work. Although I found I needed to run autogen.sh twice for it to generate all the necessary files.

source ENVIRONMENT.macports
sh genconfig.sh
sh autogen.sh
sh autogen.sh
./configure
make

This spits out the minidlna executable and a basic configuration file. Copy these to wherever you want them. Edit the minidlna.conf file, pointing it at the files you want to serve. There are examples of what to do in that configuration file.

And for testing purposes you can start the server from the build directory.

./minidlna -d -f minidlna.conf

Bingo.

I did try using ushare, another DLNA server, but I couldn’t figure out how to persuade my Sony telly to successfully connect to it. So I gave up. I feel it is useful to give up quickly when something doesn’t work until you run out of alternatives, I consider this triage. I also consider my telly’s inability to work with ushare and the fact that the telly will only play a very limited set of video formats a mark against the promise of DLNA.

Looks like it is the work of Rusty Myers and Nate Walck (so far).

However it is another 15 seconds from login to a usable desktop, running Mac OS X 10.5.8. My Macintosh Classic with an 8 MHz 68000 processor is slightly faster booting System 6.0.8. Both the mini and the classic can run some version of Eudora for e-mail. Neither machine will run Google’s Chrome browser so I reckon it is even splits on which is the more useful.

Also I don’t need an adaptor to plug in the world’s greatest aircraft carrier masquerading as a keyboard on the classic. Little baby Jesus to think that Apple used to sell their considerably expensive computers with no keyboard, no screen, no graphics card, no memory, no hard disk, just a mouse! Progress means you can buy a new MacMini and it don’t come with a mouse neither.

Use MacPorts: relatively easy to install and the best thing is everything is contained in a directory that you can be confident won’t eff up Apple’s stuff and won’t be effed up by Apple’s stuff.

Install Xcode

You need the compiler and bits that are installed with Xcode. If you can’t find your Mac install discs (Xcode is included with every new Mac but not installed) you can download it from Apple’s developer website. Registration is required but is free.

The current version of Xcode is easy to find, while older versions are available in the downloads section under “Developer Tools”. Xcode version 3.1.4 is the last version that will work for Mac OS X 10.5 systems.

Install MacPorts

MacPorts have a nice pkg installer. You can also build it from source.

curl -O http://distfiles.macports.org/MacPorts/MacPorts-1.9.1-10.5-Leopard.dmg
hdiutil attach MacPorts-1.9.1-10.5-Leopard.dmg
sudo installer -pkg /Volumes/MacPorts-1.9.1/MacPorts-1.9.1.pkg -target /
hdiutil detach /Volumes/MacPorts-1.9.1

If for some reason MacPorts cannot fetch updates you may need to pull updates by hand.

Check your $PATH after installing ports to make sure /opt/local/bin is in there. If it isn’t your can do export PATH=/opt/local/bin:/opt/local/sbin:${PATH} to fix things, and even add taht line to ~/.profile so that bash picks it up every time (assuming you haven’t switched your shell).

Install software

The port command is used to manipulate the MacPorts installation. Use it to build and install the various bits we need. This takes a while, especially on old PowerPC machines. Make it more exciting by adding the --verbose flag. Exciting!

sudo port install python26
sudo port install apache2
sudo port install mysql5-server
sudo port install mod_python26
sudo port install py26-mysql
sudo port install py26-django
sudo port install py26-south

And if you want to hook Django into a network directory then you almost certainly want to use LDAP.

sudo port install py26-ldap

Cool kids these days say use mod_wsgi instead of mod_python for hosting Python applications with Apache, but I am not cool (and on 20 September 2010 I couldn’t persuade mod_wsgi to build from MacPorts on a clean installation).

Configuring and starting MySQL

UPDATED: commenter matea pointed to Jason Rowland’s MySQL on Mac posting that includes steps to secure a default installation, so I’ve updated this section with the appropriate steps.

I always seem to be the only person who cares about non-English visitors… anyway, so I want to have MySQL use UTF8 for everything. Edit the configuration so it does. As root, create a configuration at /opt/local/var/db/mysql5/my.cnf with these lines:

[mysqld]
init-connect = 'SET NAMES utf8'
character-set-server = utf8
collation-server = utf8_general_ci
skip-networking

[mysql]
default-character-set = utf8

One thing about the line skip-networking in the configuration file is that it means MySQL will not listen to any network clients, including connections to 127.0.0.1. Instead clients should connect to localhost or they should specify the path to the socket that MySQL uses for communication. If your MySQL “client” is a Django instance running on the same host then that should not be a problem.

Now initialize the database and start the server. (The use of -w in the second line tells launchctl to have the database daemon start at boot. If you don’t want to have MySQL running at boot use -F to force start just this one time instead of every time.)

sudo -u mysql /opt/local/bin/mysql_install_db5
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

And let’s check that the server is up and configured right.

/opt/local/bin/mysql5 -e "SHOW variables LIKE '%char%'"

You should see a table showing that the character set for the client and server is set to utf8.

Now run the secure installation script for MySQL. This will ask you to set a password for MySQL’s root account (the administrator) and ask whether to remove the test database and anonymous user access (you should do both):

/opt/local/bin/mysql_secure_installation5

Thaz better.

Configuring Postgresql instead of MySQL

If you want to use Postgres instead of MySQL then you need a couple different packages out of ports.

sudo port install postgresql84-server
sudo port install py26-psycopg2

Did you know Apple’s management tools use Postgres? Is true.

Configuring Apache to serve a Django project

Let’s suppose your Django project lives under /Library/WebServer/example.com/myproj, and the project’s settings file is /Library/WebServer/example.com/myproj/settings.py. Here’s how to configure Apache with mod_python to serve your project.

Create a separate site configuration for Apache in /Library/WebServer/example.com/site.conf.

<Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE myproj.settings
    PythonOption django.root /
    PythonDebug On
    PythonPath "['/Library/WebServer/example.com'] + sys.path"
</Location>

<Directory /Library/WebServer/example.com>
    Order deny,allow
    Allow from all
</Directory>

Of course once everything is hunky dory you will go back and edit the site configuration so that PythonDebug Off.

And finally tell Apache to use mod_python and read the site configuration. Edit /opt/local/apache2/conf/httpd.conf and add a line at the end of the modules like:

LoadModule python_module modules/mod_python.so

And then a line like:

Include /Library/WebServer/example.com/site.conf

Now fire up Apache:

sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

MacPorts has a convenient shortcut for this:

sudo port load apache2

You also want to save Apache a little grief by pre-compiling the Python source files for the project:

/opt/local/bin/python2.6 -m compileall /Library/WebServer/example.com

Hope this helps.

Macintosh scrollbars work well. You can use the Appearance panel in System Preferences to change a couple things, such as whether to put the arrows at the ends of the scrollbar or at one end together (you can use TinkerTool to access more choices if you fancy) and those choices take effect immediately in a well-behaved Mac application.

Chrome is a bit naughty in that it will use your scrollbar settings but only looks at them when it starts. If you change the arrow setting while Chrome is running it will ignore your changes until the next time it launches, whereas a proper Mac application picks up those settings immediately.

Naughty Chrome.

In return for not honouring your settings immediately, Chrome’s scrollbars exhibit a fantastic behaviour: overloading the scrollbars with useful information.

If you do a word search in a Chrome window, you will see orange marks in the vertical scrollbar which indicate the location of all the matching words in the document.

Nice Chrome.

In Jenifer Tidwell‘s book Designing Interfaces she calls this design pattern the “annotated scrollbar”.

Basic environment

You must remove admin access for users, otherwise you cannot be certain where the user data is, and if you cannot isolate the user’s data then you cannot trust that updating the system won’t delete their stuff.

You really need to have the Macs bound to a directory and have account info stored in the directory. This means you don’t need to create and maintain local accounts on each Mac. It is also makes life much simpler when you need to migrate data from one Mac to another because the account uid/gid will be persistent.

Mac OS X Server

The server version of Mac OS X includes a software update server. By hosting your own local copy of the Apple software update server you conserve network bandwidth and you get to withhold what updates are presented to the Mac clients should you want to.

You also get to use Apple’s directory service and to control policy with MCX.

You don’t necessarily need OS X Server, but it is very useful.

Reporting and management suites

From there you have a bunch of approaches. Big environments (educational) use things like Radmind and Puppet to enforce software load-sets across hundreds, thousands of Macs.

For small network sizes people use Apple Remote Desktop (ARD) and/or Casper. ARD is extremely useful whatever you decide to use because the administration software includes remote desktop stuff so the help desk monkey can take over the user’s screen, fix the problem and put the telephone back down.

Although these tools handle reporting, remote installations, running scripts, batch configuration, etc. you still need to spend a lot of time building installation packages. You need a base system image that can be quickly deployed to a Mac, and you need additional images or installation packages containing the various software that goes on top.

Deploying system software and applications

To build system restore images use InstaDMG. Much better than everything else.

What you want for deploying software is some form of un-attended network push. This means the software installation has to work with access via SSH, whether the user is logged in or not and needs to succeed when installed as root.

With luck your software vendor already uses well-behaved package format installers (i.e. Microsoft most of the time). Or the software is a self-contained app so it can be installed and updated by copying it to /Applications (maybe you go to the trouble of making a pkg for it first).

But flipping heck Adobe hates Mac administrators. The Adobe Creative Suite installers (including those on volume license media) are absolutely useless. The updaters are even worse. Adobe provides a volume deployment kit which is bafflingly obtuse and which doesn’t actually work for the admin’s most important installation scenario.

Casper and LANRev include tools for building pkg installers from the Adobe media. Adobe’s enterprise kit supposedly does the same thing. The other thing you do is build your own pkg from what gets installed. That isn’t too painful, but having to build your own update pkgs for the numerous Adobe updates is painful.

(The Apple Installer-Dev list is full of developers trying to work around bugs in PackageMaker that crop up as soon as you want to do anything other than copy files to disk. Many admins prefer Iceberg or Packages and other software for building installer packages.)

System configuration and user preferences

To some degree you configure the system as part of building the base image. Things like have the Mac automatically configure the network, bind to a domain, set power-saving mode, disable auto-login, etc. should all be part of a first-run script that happens when a new Mac is switched on.

In general you should avoid changing the default settings for everything else, either per-Mac or per-user. Saves you much hassle.

Most software these days uses plist format and reads the settings from the correct places (even recent versions of Office are good at this). Adobe of course doesn’t, but I have infinite patience. Assuming all the prefs you need to manage are in plist format, you either just run scripts to set things on an ad-hoc basis or you enforce policy with login hooks. If you use Open Directory to manage Macs you can use the Mac OS X Server tools to push settings to all users. Since 10.5 you can use each Mac’s local directory in much the same way as Open Directory to manage settings too (although you need to then handle updating each Mac yourself).

You can use login/logout hooks which run for each user. You usually find if you run a system-wide script to adjust per-user settings that at some point you mess up the permissions, no matter how careful your script is. The other approach is to use per-user launchd scripts, although they were effectively broken in 10.4 and not much better in 10.5. The launchd man pages are required reading even so.

Interesting bits

• Mac OS X Server docs: http://www.apple.com/server/macosx/resources/documentation.html
• Macos-x-server mailing list: http://lists.apple.com/mailman/listinfo/macos-x-server
• Munki, for deploying software: http://code.google.com/p/munki/
• DeployStudio, like Casper: http://www.deploystudio.com/Home.html
• AFP548, fantastic tips: http://www.afp548.com/
• Mike Bombich, admin: http://www.bombich.com/
• Greg Neagle, admin: http://managingosx.wordpress.com/
• Preston Holmes, admin: http://ptone.com/dablog/
• MacEnterprise mailing list: http://www.macenterprise.org/mailing-list
• MacManagers mailing list: http://www.mac-mgrs.org/
• Adobe installer blog: http://blogs.adobe.com/oobe/

Best software ever

When this feature first appeared, one could trigger a stupid bug if one happened to have an application other than Preview.app set as the default application for files with the .pdf extension. If you had Adobe Acrobat set as your default PDF viewer, then hitting the preview button in print dialog boxes would open that preview in Acrobat.

It was a stupid bug, particularly because it was so obvious what was going wrong. The preview was being written to a temporary file with a .pdf extension and then being opened using whatever handler was defined in launch services. But you don’t want that, you want it to be handled by the operating system and not be subject to whether or not you have the patience to wait thirty seconds while Acrobat version 6 merrily paints its splash screen for your pleasure.

Later versions of Mac OS X fixed this so that the print preview is always displayed using Preview.app. This happens even if you set Acrobat as the default application for .pdf files, and it is a good thing it behaves like this. (In fairness, launch times for Acrobat since version 8 are no longer painful.)

I tested what happens if you delete Preview.app on a clean 10.5.8 install: the system falls back to opening QuickTime Player.app for displaying previews (which works fine). And if you delete QuickTime Player.app it falls back to using Safari.app (also works fine). And if you delete Safari.app it falls back to TextEdit.app (which works fine as long as you can render raw PDF data in your head).

It is as if going by the default association between file extension and application was not enough; that the system had a need to use a particular bit of software for these PDF preview files, regardless of what software was chosen as the handler for a different set of PDF files. Who’d have guessed?

All of this is an argument for providing a programmatic way to set the owning application for a file. You might call this a creator code, potentially any file could have one, but no biggie if it was not present because you could fall back to some regular stupid heuristic for determining the owner.

And then in Mac OS X 10.6 you might change the behaviour of the system so that this useful and important information about the file is ignored. Grumble.

Dammit, only just occurred to me to see whether the system would eventually fall back to using Acrobat itself for displaying previews. Grumble.

His first point is that Mail.app gives you a big warning before doing the dirty. I don’t think that excuses the bad behaviour. Warning someone that you behave badly does not excuse that bad behaviour (my ex says this rule applies in more cases than the implementation of mail clients).

His second point is that the user should have a backup; with a good backup she can recover from her mistake when all those old messages disappear. I agree that people should have backups, but I don’t think that argument has any weight because you can imagine that the answer for all bad design decisions is “you should have had a backup”, in which case there are no bad design decisions.

The problem is that Mail.app’s insistence on a POP account being a separate set of folders means a message cannot appear in the Inbox unless it belongs to an account. If you delete a POP account then you have to move the messages to the Inbox of another account just to keep them appearing in the Inbox. This does not make sense.

Suppose you have a large history of messages received via a POP account. Then you delete that account and switch to an IMAP service with a meagre storage limit. If you want to keep those old messages appearing in the Inbox you must move your the historic Inbox messages to the IMAP account’s Inbox even though that will take up space on the server (and there may not be sufficient space on the server for them anyway). The other option is to give up the idea that old messages belong in the Inbox and just move them to local folders “On My Mac”.

If Mail.app provided a local Inbox folder that appeared as part of the unified Inbox then my objections would go away. (There should also be a corresponding local Sent folder.)

IMAP and POP are different in that a POP account’s mailbox is really just a temporary queue for messages that have yet to be retrieved by the client. Mail.app should recognize that difference and stop pretending that the two types of account are equivalent.

Quite pleased that Hawk Wings even knows my blog exists. Hawk Wings is good.

I always liked that Outlook Express and Entourage defaulted to plain text for messages. I particularly liked the fact that OE / Entourage defaulted to bottom-posting when replying to a message – as any fule kno top-posting is a hideous convention foisted on us by miserable office mail systems back when there was still a chance that your e-mail would not be delivered via SMTP (Exchange version 5 and earlier is the primary culprit here).

I still get annoyed that when using Mail.app hitting the tab key in a plain-text e-mail inserts a tab character instead of expanding it to four spaces like Entourage.

Given enough time this post would devolve into arguments about top-posting versus bottom-posting, the width of the one true tab-stop and how HTML e-mail has turned our youths’ minds into mush.

The problem is related to how Mail.app stores messages for an account. For an IMAP account (or a Microsoft Exchange account) Mail.app creates a folder on the local disk and creates mailboxes within that folder corresponding to the mailboxes on the server. The contents of those mailboxes are synchronised with the contents of the mailboxes residing on the server. This makes perfect sense because with IMAP because the messages live on the server – keeping a local copy of those messages is effectively a performance optimisation.

What is weird is that Mail.app uses the same strategy for POP accounts, even though with POP there is only one mailbox on the server and it is effectively a temporary store for messages, which is to say that with a POP account a message does not live on the server but moves from one mailbox to another until it reaches its final resting place, that place being on the client.

The only copy of a message received via POP is on the client. (Having said that, Gmail’s POP support muddies the waters because issuing a DELE command does not actually delete the message from the server, but the principle is the same.)

Now when you go to remove an IMAP account Mail.app deletes all the local mailboxes for that IMAP account. This is not a problem, after all those local mailboxes are simple caches; the only reason the client keeps a copy is as a performance optimisation (as noted above).

Now when you remove a POP account Mail.app deletes all messages sent or received via that account, even though there will be no copy of those messages on the server (especially true for sent messages). This is not useful or intuitive – it is a bad design.

Why is this a bad design? It is a bad design because with an IMAP account you understand that the messages live on the server whereas with a POP account you understand that the messages live on your local hard drive. With an IMAP account you understand that removing the account removes your access to those mailboxes that exist on the server, whereas with a POP account it makes no sense that the act of stopping the retrieval of messages from the account implies that all the messages received via that account and now stored on your hard disk should be removed as well.

Earlier versions of Mail.app had an even more destructive behaviour when removing a POP mailbox. In the version of Mail.app that shipped as part of Mac OS X 10.4, if you removed a POP account then all messages associated with that account were removed without warning. Now imagine the not uncommon sequence of events for someone changing from POP account A to POP account B using earlier versions of Mail.app:

1. User accumulates years of e-mail using POP account A.
2. User adds new POP account B.
3. User removes POP account A.

At step 3 the user lost all her historic e-mail! Apple finally realised that this was no way to win friends and so introduced a confirmation specifically warning that messages would be lost before deleting a POP account (this change was introduced with Mac OS X 10.5).

Another unfortunate behaviour is how Mail.app handles a disabled POP account. Disabling an account stops Mail.app from using that account for sending and receiving but also removes all the associated messages from the Inbox.

It is possible to keep an old POP account enabled so that its messages are still displayed but then turn off the preference to “Include when automatically checking for new messages”. This leaves the old account available when composing a new message as a choice in the From field so one must also change the preference for “Send new messages from” to always use the new POP account in order to avoid inadvertently sending a message using the old From address (or edit the from address in the old account to match that in the new account).

Microsoft Entourage has a better approach to this situation: messages for POP accounts are delivered to the Inbox mail folder “On My Computer”, and they stay there when the POP account is deleted. The flaw in Entourage’s approach is that the local folders appear even when all your e-mail accounts are server-based (i.e. all IMAP and / or Exchange accounts). I think it would be better to create those local folders only when a POP account has been defined because if you have only server-based accounts then it is distracting to have a set of folders called “On My Computer” which have no purpose.

I tell them that a lot of things are the same, that their new computer will still go wrong in frustrating ways and that the Finder is the way it is for historical reasons. The most productive part of the conversation is suggesting bits of software that make your computing career on Macintosh less painful…

Growl! What a fantastic piece of software. Mac OS 9 introduced modeless notifications and it was immediately obvious why it was a good thing. Before then you could bring a Mac server to a halt just by holding down the mouse button for too long, and many Mac applications wanted to get your attention by throwing up a global dialog box to let you know when something had happened. Due to the classic Mac relying on co-operative multi-tasking a modal dialog box could not only interrupt the front-most application but also stop all background applications until the dialog box was dismissed. So Mac OS 9′s mode-less notifications were a great thing.

On Mac OS X there is no built-in API for posting global mode-less notifications. Growl fills that gap. Growl provides an API for Mac applications to post notifications and it presents those notifications in an unobtrusive manner, floating small windows on the top of your desktop that can be easily dismissed or ignored.

The truly great thing about Growl is how it has been adopted by developers. BBEdit uses Growl; Cyberduck uses Growl; pretty much every great Mac application supports Growl because it is such an excellent way to post notifications.

An example of Cyberduck's upload complete Growl notification

And so it seems to me that Mac OS X itself should support a Growl-like API for notifications. Either the operating system should take advantage of Growl when a user has installed it or Apple should just ship Growl as part of the system to provide its functionality as a standard API for any application to post notifications.

I believe there is a need for such an API. Witness the Google Notifier application which does not use Growl for notifications but instead chooses to post floating mode-less notification windows that look an awful lot like Growl’s notifications but which behave in a subtly different manner. Annoying.

Microsoft’s Mac installers are good, but unnecessarily complicated. And the design of the Mactopia website drives me up the wall – tiny little scrolling <div> blocks and javascript hyperlinks makes it difficult to read the information and difficult to link straight to an update.

But I disagree that the correct cursor to use for a blocking task that cannot be cancelled is the spinning beachball of death. That cursor after all is the cursor automatically provided by the operating system when an application is not responding to input events. As such when I see the beachball I associate it with a stuck application, one that may need to be forcibly quit.

Previous versions of Photoshop showed the watch cursor for actions which took a significant length of time. Showing the watch cursor is friendlier than showing the beachball of death because it indicates that the application is busy, too busy to handle your clicks but everything is hunky dory and the train will arrive at the station.

There is no watch cursor listed in Apple’s documentation on cursors. However the cursor is still present in the system and can be found in the headers for the carbon appearance manager:

kThemeWatchCursor             = 7,    /* Can Animate */

If you have Xcode 3.2.2 installed you can find this in /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/Appearance.h, line 634.

I don’t know enough about Macintosh programming to say whether it is possible to employ this cursor from a Cocoa-based application.

The next problem was that MacPorts couldn’t update because rsync was blocked by the corporate access policy. Fortunately plain HTTP is permitted outbound. Here’s how to use a local ports tree.

Install MacPorts using the disk image for 10.5.

curl -O http://distfiles.macports.org/MacPorts/MacPorts-1.8.2-10.5-Leopard.dmg
hdiutil attach MacPorts-1.8.2-10.5-Leopard.dmg
sudo installer -pkg /Volumes/MacPorts-1.8.2/MacPorts-1.8.2.pkg -target /
hdiutil detach /Volumes/MacPorts-1.8.2

If the MacPorts install directories are not in your $PATH environment, you can add them to your .profile. This change will not take effect until you start a new terminal session.

cat >> ~/.profile <<EOF
PATH=/opt/local/bin:/opt/local/sbin:${PATH}
MANPATH=/opt/local/share/man:${MANPATH}
EOF

After you have installed MacPorts, create a directory for the ports tree and check it out using Subversion.

sudo mkdir -p /opt/local/var/macports/sources/svn.macports.org/trunk/dports
cd /opt/local/var/macports/sources/svn.macports.org/trunk/dports
sudo svn co http://svn.macports.org/repository/macports/trunk/dports/ .

N.B. In the last line beginning svn co ... the trailing directory separator is significant!

Now tell MacPorts to use the local checkout rather than rsync. Edit /opt/local/etc/macports/sources.conf and add a new line to the end with the path to the ports tree, then comment out the previous line that uses rsync. Here are the last lines from my configuration:

#rsync://rsync.macports.org/release/ports/ [default]
file:///opt/local/var/macports/sources/svn.macports.org/trunk/dports/ [default]

Finally you must create an index for the tree (otherwise you will see messages saying “Warning: No index(es) found!”).

cd /opt/local/var/macports/sources/svn.macports.org/trunk/dports
sudo portindex

Now go do great things.

Many thanks to Preston Holmes for releasing watchedinstall in the first place.

My goal is to replace the functionality of the fsevents helper application with a dtrace script that can list filesystem changes. A single python script would be simpler to install and use – you wouldn’t need to install it at all, just run it from the directory you downloaded it to. No effing about with setting PATH environment variables, no worry about compiling a C program for whatever architecture.

Hey Esther!