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.

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>]’.

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 \{\} \;

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());

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!

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.