If you are finding mail sometimes not appearing in your Mail inbox after upgrading to Snow Leopard, but then it appears again once you restart Mail, try shutting off the ‘Use IDLE command’ option in account settings. (Its at the bottom of the advanced tab).

After upgrading to Snow Leopard on my Mac, I noticed this was happening with email in my Dreamhost IMAP account.

I’ve been running with the ‘IDLE’ option turned off for a day, and it seems to be working correctly again.

Since the latest Mac operating system Snow Leopard adds Exchange support to iCal, I thought maybe now I could reach the holy-grail: Syncing my work calendar, in Exchange, to Google Calendar.

This would effectively let me see my business meetings on my Android-based cell phone.

I had tried various tricks and tools before, but nothing ever quite worked. But today I tried BusySync, and it seems to work great.

All you need to do is setup iCal to access your Exchange server, then in BusySync’s Google tab, check the off the calendar you want to upload in the ‘Publish to Google’ list.

There are two problems with this solution however:

1. Changes made to the calendar on Google aren’t synced back to iCal, and worse, they seem to be lost from Google.
2. The calendar name shown in Google is pretty awkward, its currently ‘Calendar[<user@exchangeserver>]’.

I was hoping to try out Spanning Sync and see if it’s similar features would handle Exchange calendars as well, but unfortunately I have tried Spanning Sync in the past, and my trial has expired, so I can’t evaluate its behavior.

When I upgraded from a PowerBook to a new MacBook Pro, I used Windows File Sharing (also known as Samba or SMB sharing) to transfer all of my files from one computer to the other via a network, and it looks like that corrupted my Aperture Library.

It look me a few days to realize the problem, but here are a few symptoms I noticed:

1. Images that were in the library BEFORE the move were not visible in iLife applications (iPhoto, the screen saver, etc). The projects appeared in the listings, but the images themselves were not visible. For example, the screen saver would always say “The selected folder contains no pictures. Please choose a new folder that contains pictures or add images to the folder.”
2. Managed RAW images would not display correctly. I would click on them and the image would appear with a ‘loading’ message, and then eventually I would see a solid red or maroon background with the text “Unsupported Image Format”.

Knowing that the Aperture Libary is just a special directory (called a bundle in Mac-speak), I started poking around inside, comparing a good project (one that I had imported on my new MacBook) to a bad project (one that has been around BEFORE the upgrade).

It turns out that there were directories within the Aperture project directories whose names must have gotten corrupted when I copied the project over from my old computer.

So I wrote a small program to repair the damage. If you have a similar problem, feel free to use this script to help recover your library.

Make sure you close Aperture and BACK UP your Aperture Library before you start!

Ok, now that you’ve backed up your library, download the fixApProject.sh script and save it to your home directory.

Open up Terminal.app (Application->Utilities) and cd INTO your Aperture Library.

If your library is in the default location, do it like this:
cd ~/Pictures/Aperture\ Library.aplibrary/

Now, assuming you’ve put fixApProjech.sh in your home directory, run the following commands:

chmod +x ~/fixApProject.sh

find . -name "*.approject" -type d -exec ~/fixApProject.sh \{\} \;

A few days ago I posted an article about my wrapper API which unifies the mDNSResponder and JmDNS packages behind a single interface, but I neglected to provide usage examples or a usage guide. I’ll try and correct that now.

In addition to unifying multiple mDNS implementations under a single API, I think my API reduces the amount of work needed by the developer for registering and listening for services to a minimum.

Building the code
First off, all you should need to compile and run my package is Maven. Once you have Maven installed, cd into the jmdns directory, and run:

mvn test

This will compile JmDNS, my add-on API, and run a few unit tests. The API in question is tested by org.jmdns.api.DiscoveryFactoryTest. I would expect the JmDNS portion of the test testJmDNS() to pass under almost any circumstance, but the testmDNSResponder() will only pass if you are running on Linux and have mDNSResponder (or possibly the avahi compatibility layer) installed successfully.

Example usage – Initialization

Before registering or listening for services, you need to initialize the discovery subsystem:

DiscoveryFactory.initRegistry( DiscoveryFactory.DISCOVERY_REGISTRY_DEFAULT);

The above will use the default mDNS implementation (JmDNS). Alternatively you can use the following to use JmDNS explicitly:

DiscoveryFactory.initRegistry( DiscoveryFactory.DISCOVERY_REGISTRY_JMDNS);

Or mDNSResponder instead:

DiscoveryFactory.initRegistry( DiscoveryFactory.DISCOVERY_REGISTRY_MDNSRESPONDER);

Consider this an initialization a singleton, you should do this once and only once per JVM instance.

Example usage – Registering a Service

Assuming the system is initialized, the following code will register a service:

HashMap<string,> props = new HashMap<string,>(); props.put("type", "website");</string,></string,>

IDiscoveryRegistry registry = DiscoveryFactory.getRegistry();

IServiceInfo myService = registry.registerService("_http._tcp", "mySite", null, 80, props);

Note the ‘null’ in the registerService() call is to use the default domain (.local). You can pass a domain name here to register in another domain.

To unregister your service, just do:

registry.unregisterService(myService);

Example usage – Listening for a Service

Create a listener:

BaseDiscoveryListener listener = new BaseDiscoveryListener("_http._tcp", "website", null);

Wait 15 seconds for a service:

listener.waitForFirstService(15000);

Get the first service found:

IServiceInfo service = listener.getFirstService();

Print out some information on the service:

System.out.println("service name: " + service.getName() + " at " + service.getHostAddress() + ", port: " + service.getPort());

My company has given me permission to release a Java Zeroconf API. The advantage of this API is that it allows the application to select which implementing library to use at runtime, and eases developer work implementing mDNS / DNS-SD. I also think my API is easier to understand than the raw interfaces of the underlying implementations.

Currently there are two implementing backends, one for JmDNS and one for Apple’s mDNSResponder. I would really like to see one written for Avahi, but I probably won’t get to it myself.

The API is in the org.jmdns.api package, which both implementations are in the org.jmdns.impl package. A unit test is also included which demonstrates usage and verifies operation.

I’ve implemented this version within the JmDNS source tree, but ideally the API, JmDNS and mDNSResponder portions of the code would be broken out to be separately distributed, with the JmDNS and mDNSResponder portions functioning as plugins implementing the API.

I’ve only tested this against mDNSResponder 107.5. I’m not sure if Apple’s dnssd.jar is compatible with newer mDNSResponder versions or not.

You can download the full implementation here: jmdns-kiva-1.1.3.tar.bz2

I hope the JmDNS project will pick this effort up and incorporate this into the official release!

A while back my Mac starting taking really long to wake from sleep. I’d get a spinning beachball (SBOD) for 30 seconds before the login screen would appear, and it would take a while for my password to authenticate.

I also noticed that when I started Terminal or iTerm, it took forever. First it took forever for the window to even appear, and then when it did the “last login” line would appear, pause, and then about 30 seconds or more later, the prompt would finally appear and you could use the terminal normally.

I searched the web all over for help on this and did a few maintenance things, but nothing helped. One person online found the solution to their problem by running ‘top’ and watching the login process, but nothing out of the ordinary was happening on my machine.

Then it dawned on me: The exact same thing happens on my Linux machines when the LDAP settings aren’t working correctly, because the LDAP timeout defaults to around 30 seconds.

So I started Directory Access, and sure enough, there was an LDAP server listed under the Authentication tab. I had recently added the same server for the Contacts tab, but I didn’t expect or want to use it for authentication.

Removing the LDAP server cleared up my slow logins and terminal starts, so make sure you check Directory Access if you are having a similar problem.