This behavior can have unfortunate side effects in applications. Especially remote applications that work path based and interact with different operating systems can run into problems here.

I came across this when I tried to access a subversion repository that contained file names with German umlauts from my Mac. I am running subversion 1.6.5 and when I check out a file with an umlaut in its name, executing “svn stat” will list the file twice, once as missing (with an ‘!’) and once as unversioned (with a ‘?’). A search in the collabnet discussion forums finally confirmed that this is a know issue. The following links provide some documentation:
http://www.opensimwiki.net/index.php/SVN
http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames

However, the subversion issues are just one specific bug. For application developers it is important to know that Unicode equivalence is a term to keep in mind. The wikipedia article (http://en.wikipedia.org/wiki/Unicode_equivalence) mentions a bug in the samba protocol due to different representations of Unicode characters.

So, next time you come across an issue that involves a Mac and umlauts, Unicode equivalence might be the term to look for.

Eclipse error message: "Cannot complete the request. This installation has not been configured properly for software updates!"

To fix this, you need to go to “Preferences > General > Capabilities” and check “Classic Update”. Afterwards you should be able to select “Help > Software Updates > Find and Install…”.

I wasn’t able to find much on the internet, but this post on an Ubuntu forum finally brought the solution.

/System/Library/Frameworks/JavaVM.framework/Versions/

directory all point to “CurrentJDK”, which points to “1.6″. The thing is that Snow Leopard ships with a 32 bit version and a 64 bit version of the VM (Virtual Machine), 64 bit being the default one. The Java Preferences app shows this nicely:

And that is the big news about it, since a 32 bit version of java 6 didn’t previously exist for OS X.

Now I’ve previously had to tweak Eclipse to use the 1.5 VM (see “Java Versions on Mac OS X“), and now it just works. I’m assuming that this is because of the “mixed mode”:

$ java -version
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)

…so the VM would automatically detect if an application should be executed in 64 or 32 bit mode and then start the correct VM. I still need to investigate how this actually works. Anyway, the good news is that java and eclipse seems to be working better with Snow Leopard. I’ll write more on this as I continue working with it, for now here is an interesting post on the topic:

http://blog.zvikico.com/2009/09/eclipse-java-and-snow-leopard.html

$sudo lsof -Pi | grep -i "listen"

FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
Man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man

$ mvn --version
Maven version: 2.0.9
Java version: 1.6.0_07
OS name: "mac os x" version: "10.5.6" arch: "x86_64" Family: "mac"

In this case, maven 2.0.9 is running, so we’ll see how to switch to maven 2.0.6. First we need to know where the maven executable, or in this case, the symbolic link to the executable is located:

$ which mvn
/usr/bin/mvn

Next, we’ll use ls to check where the symbolic link is pointing:

$ ls -l /usr/bin/mvn
lrwxr-xr-x  1 root  wheel  24 Apr 24 14:26 /usr/bin/mvn -> /usr/share/maven/bin/mvn

Finally, if you have different maven versions installed, you can switch between them by overwriting the symbolic link:

$ sudo ln -fhsv /usr/share/maven-2.0.6/bin/mvn /usr/bin/mvn

After providing your password, the symbolic link should now be pointing to the maven 2.0.6 executable. To doublecheck, type

$ mvn --version

The output should be something like this

Maven version: 2.0.6

We’ll first create a src folder in your user directory, download mod_auth_mysql and expand it:

$ mkdir ~/src
$ cd ~/src
$ curl -O http://puzzle.dl.sourceforge.net/sourceforge/\
modauthmysql/mod_auth_mysql-3.0.0.tar.gz
$ tar zxvf mod_auth_mysql-3.0.0.tar.gz

Now you have the sources of the module in the folder mod_auth_mysql-3.0.0. Before we can compile it, the patch has to be applied. Here is the diff file mod_auth_mysql, save it to

~/src/mod_auth_mysql-3.0.0/mod_auth_mysql.diff

To apply the patch, we change to the sources directory and execute the unix patch program that takes the original file and applies the diff file as patch:

$ cd mod_auth_mysql-3.0.0
$ patch mod_auth_mysql.c mod_auth_mysql.diff

Now we are ready to compile the module, install it and add it to http.conf, the apache configuration file. Apache modules are compiled using apxs, the APache eXtenSion tool. Before we start, lets look at the command:

$ sudo apxs -c -i -a -D lmysqlclient -lm -lz \
-I/usr/local/mysql/include/mysql/\
-L/usr/local/mysql/lib/ -Wc,"-arch x86_64" \
-Wl,"-arch x86_64" mod_auth_mysql.c

We should execute apxs as super user because it will attempt to install the module to /usr/libexec/apache2/, so we prepend the command with sudo. the -c option tells apxs to compile the module, -i to install it and -a to add a line to http.conf, telling apache to load the module. The -I and -L options are used to provide information about where MySQL is installed and where to find the mysql.h file. I compiled and installed MySQL from source and installed it in the /usr/local/mysql/ directory, if your installation is in a different place, you might have to adjust these parameters. (An excellent guide on compiling and installing MySQL on OS X is available at http://hivelogic.com: “Installing MySQL on Mac OS X“)

When you execute the above command, you should see an output like this:

/usr/share/apr-1/build-1/libtool --silent --mode=compile gcc    -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp  -I/usr/include/apache2  -I/usr/include/apr-1   -I/usr/include/apr-1  -arch x86_64 -I/usr/local/mysql/include/mysql/ -Dlmysqlclient  -c -o mod_auth_mysql.lo mod_auth_mysql.c && touch mod_auth_mysql.slo
/usr/share/apr-1/build-1/libtool --silent --mode=link gcc -o mod_auth_mysql.la -arch x86_64  -L/usr/local/mysql/lib/ -lm -lz -rpath /usr/libexec/apache2 -module -avoid-version    mod_auth_mysql.lo
/usr/share/httpd/build/instdso.sh SH_LIBTOOL='/usr/share/apr-1/build-1/libtool' mod_auth_mysql.la /usr/libexec/apache2
/usr/share/apr-1/build-1/libtool --mode=install cp mod_auth_mysql.la /usr/libexec/apache2/
cp .libs/mod_auth_mysql.so /usr/libexec/apache2/mod_auth_mysql.so
cp .libs/mod_auth_mysql.lai /usr/libexec/apache2/mod_auth_mysql.la
cp .libs/mod_auth_mysql.a /usr/libexec/apache2/mod_auth_mysql.a
ranlib /usr/libexec/apache2/mod_auth_mysql.a
chmod 644 /usr/libexec/apache2/mod_auth_mysql.a
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/libexec/apache2

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable
     during execution

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 755 /usr/libexec/apache2/mod_auth_mysql.so
[activating module `mysql_auth' in /private/etc/apache2/httpd.conf]

If there are no error messages, you can test the apache configuration with apachectl:

$ apachectl configtest

If the output is

Syntax OK

you can continue by restarting apache:

$ sudo apachectl graceful

The next step would be to set up your locations in http.conf, but that’s for another time…

I just started using my Mac as a development machine and thought I’d share some of the issues and solutions I came across. I’m using Java 6, Tomcat 6, Eclipse 3.3.2 (Europa), hibernate 3, Spring 2.0.3 and tapestry 1.4.5.

The first issue I came across was an

UnsupportedClassVersionError: Bad version number in .class file

error when I tried to start tomcat. (I’m using the sysdeo plug-in to control tomcat, even though I’m aware that WTP is much better… I have my reasons, but that’s beyond the scope of this post.)

Now the title of the console in Eclipse revealed the problem, the Sysdeo plug-in was using version 1.4 of the Java RE. The thing is, I didn’t notice this until I tried a whole bunch of other stuff… which cost me quite a bit of time, but also helped understand a few things better.

OS X keeps the different Java versions neatly separated in the

/System/Library/Frameworks/JavaVM.framework/Versions

directory. By creating or overwriting the symbolic link “CurrentJDK”, you can change the default JDK version of your system. To do this, you have to change to the Versions directory and set a new symlink with ln:

$cd /System/Library/Frameworks/JavaVM.framework/Versions
$sudo ln -fhsv 1.6 CurrentJDK

After providing the administrator password, the default JDK will be set to version 1.6. Unfortunately, after doing this, I couldn’t start Eclipse anymore. The fix for this is to edit the following file:

/Applications/eclipse/Eclipse.app/Contents/Info.plist

and un-comment the following line:

<string>-vm</string><string>/System/Library/Frameworks/
JavaVM.framework/Versions/1.5.0/Commands/java</string>

This tells Eclipse to use a specific Java version, instead of the platforms default one. Now I was able to start Eclipse again and tomcat started without exceptions when I manually deployed my war files. My next step was to try Sysdeo to start Tomcat, which is where I realized that all I would have had to do was to set the correct JVM in Preferences > Tomcat > JVM Settings. Anyway, learned something on the way

Here are some links that helped me:

http://blog.kischuk.com/2008/05/08/running-eclipse-on-macbooks-with-java-6/

http://www.insanelymac.com/forum/index.php?showtopic=58817&st=0&p=435204&#entry435204

http://johnnywey.wordpress.com/2008/06/21/os-x-and-java-unsupportedclassversionerror/

So after a lot of hesitation I settled for the Qnap TS-409 Pro and decided to start off with two 1TB Western Digital (Caviar Green WD10EACS) hard disks. This setup would allow me to start with a RAID 1 Mirroring Disk Volume configuration, effectively leaving 1 TB for use and mirroring the disks so I can be sure that even if a hard drive fails, my data won’t be lost. Later on I can still add two more disks to extend the capacity and I don’t even have to switch the 409 off for that. Another nice feature is that the TS-409 has three USB ports and supports automatic sharing of attached USB hard drives. This way I can continue using the external hard disks I bought before. So much for the server and hardware side of my NAS backup experiment. Lets look at the Software side.

The main scenario I want to be prepared for is a total system failure that requires me to restore or re-install my OS. So I needed a solution that writes bootable disk images and gives me a way to restore them. Since OS X provides a standard image format and the Disk Utility that you can start from the OS X installation disk and that enables you to mount and restore these image files, all a good backup tool needs to offer is a way to create both full and incremental backups. SuperDuper! does this and it is affordable, so I chose to try it.

It turns out that the free version of SuperDuper! enables you to write fully functional backups that you can mount or restore afterwards. By mounting them, you can browse your backup as if it was an actual physical drive. The only restriction of the free version of SuperDuper! is that it doesn’t support incremental backups. Since you’ll only need these later anyway and I was eager to get started, this was the perfect deal for me.

Up to here, everything went really smooth. But of course I wanted more. Since Leopard has Time Machine built in and it gives you such a nice interface to browse snapshots of your file system, I felt like it would be a good addition to SuperDuper!. In fact, on their web site, the developers of SuperDuper! even call it the perfect companion to Time Machine. The fundamental difference between the two is that SuperDuper! gives you a full backup that you can use to restore your system in case the hard disk fails or you mess up your system in some other way. Time Machine on the other hand creates hourly, daily and monthly snapshots of your files and provides an intuitive and simple user interface to browse them and restore them to previous states. I believe a sensable setup is to exclude all system files and basically only let Time Machine back up your data (Users directory) and leave the responsibility for system backups to SuperDuper!.

So much for the theory, but here comes the problem: Time Machine doesn’t support network drives. Luckily there is a simple solution for this. Open up a Terminal window and execute the following command

$ defaults write com.apple.systempreferences
TMShowUnsupportedNetworkVolumes 1

BTW, in case you are worried about messing up your system with this or not knowing how to revert it… the answer is simple

$ defaults write com.apple.systempreferences
TMShowUnsupportedNetworkVolumes 0

Seems logical, doesn’t it

Afterwards you can open the Time Machine preferences in System Preferences and by choosing “Change Disk…” select your network drive. Unfortunately, that isn’t where the story ends though. After kicking off the first backup by selecting the Time Machine icon in the menu bar and then selecting “Back Up Now”, I got the error message “Time Machine Error – The backup disk image could not be created.” Luckily there is also an easy solution for this. We first need to look at whats happening here though. Time Machine seems to be creating an image file on the network drive. You can actually see the file being created but when Time Machine fails, it removes it. The name of the file that is being created contains the computer name, followed by an under score and the MAC address of the primary ethernet device (en0) without colons. Our workaround will be to manually create this file with the Disk Utility and then copy it over to the network drive we have selected in the Time Machine preferences.

So now you can either look up your MAC address by typing in “ifconfig” in the Terminal, looking for en0 and then checking what it says after ether or you can try to copy the file name while Time Machine temporarily creates the image file. Either way, you should end up with a file named <computer-name>_<mac-address-without-colons>.sparsebundle. Note that the .sparsebundle extension is added automatically by the Disk Utility. Now you just have to open the Disk Utility, click “New Image”, type in the image file name and select “sparse bundle disk image” as image format and set a reasonable volume size. The thing to keep in mind here is that the image file won’t initially have the file size you select here but will be able to grow to a maximum of this size. I actually found a very interesting and useful article about this here. After clicking “Create” and waiting a bit, the image file will be created and we can copy it over to the network drive. After starting a Time Machine backup by selecting “Backup Now” from the menu, I finally ended up with this…

I found quite a lot of discussions and hints about this topic on the internet. Here are the articles that really helped to solve the problem:

• Time Machine backups on network shares in Leopard
• Using Leopard Time Machine to Backup of a Network
• Time Machine with Network drive

A thread in the apple discussion forum suggests that the Time Machine backup might fail when the computer name contains certain characters. According to the post, the following characters are safe to use in the computer name: 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

I hope this is useful for some people. Have fun and feel free to comment!