While reports suggest that it supports synching playlists in MTP mode flawlessly, my experience – as a Mac user – is that creating playlists with the device in MSC mode is tricky. Although the Fuze supports M3U playlists, it is very picky about the format. Get it wrong, and the Fuze will refuse (refuze?) to read it, rendering it simply as [Empty]. Thanks to various people on the Sansa forums I better understand the Fuze’s quirks and have hacked together the following script to generate playlists:

   #!/bin/bash

   # ---------------------------------------------------------------------------- #
   # Sansa Fuze M3U playlist creator                                              #
   #  - run from $SANSA_ROOT/MUSIC                                                #
   # ---------------------------------------------------------------------------- #

   # Don't descend more than 1 level.  In my collection each directory represents
   # an album.  Multi-disc albums - with the individual discs in subdirectories -
   # will have all discs in a single playlist, which is what I want.
   for file in $(find . -maxdepth 1 -type d)
   do
      if [ $file != "." ]
      then
         # Write the playlist in the main album directory
         cd $file
         # Tell find to render the names of the MP3s that it finds using the
         # Windows standard CR-LF line terminator.  (Sansa requirement)
         find . -name \*.mp3 -printf %p\\r\\n | \
         # Convert the '/' file separator to the Windows standard '\' (Sansa
         # requirement).
         sed -e '/\//s//\\/g' | \
         # The Sansa doesn't seem to handle relative paths correctly.  If the
         # filenames in the playlist contain a leading '.\' the device cannot read
         # the playlist and renders it as '[Empty]'.  So we cut those characters
         # from the filename/path produced by 'find'.
         cut -b 3- > $file.m3u
         # Head back for more ...
         cd - > /dev/null
      fi
   done

   WARNING: terminal is not fully functional

After bit of digging I finally realised that it isn’t enough to have entries for those terminal types in /usr/share/terminfo/*/*. Some apps expect to find the terminal capabilties described in a termcap file, either /etc/termcap or ~/.termcap. Fortunately, there is an easy way to export the capabilities described in the terminfo database entries to a termcap file:

   $ infocmp -C xterm-256color >> ~/.termcap

If you’re a screen user, its worth exporting the entry for screen-256color too. man infocmp for more information.

Hannu Nevalainen posted a solution to this problem to the Cygwin mailing list. The problem relates to the use of C-S and C-Q as the ASCII XOFF and XON flow control characters respectively. Having hit C-S, simply hit C-Q to store the bash session.

It seems that my education is lacking some terminal history!

After booting into Windows, I used the Logical Disk Manager to delete the ext3 and swap partitions and create an NTFS partition. All was well until my next reboot, when I was greeted with:

   GRUB Error 17

GRUB had been installed to load its configuration files from the Linux partition. Which I’d blitzed. I now needed some way to overwrite GRUB with the Windows bootloader. Traditionally this is achieved using fdisk by running:

   fdisk /mbr

With Windows XP, fdisk is available from the Recovery Console; boot from the Windows XP installation CD and follow the prompts until you are given the option to recover an existing Windows installation. Unfortunately – due perhaps to some quirk of how GRUB installed itself – the Windows Setup process blue-screened at the

   Setup is starting Windows

stage. I could have booted Linux using a LiveCD and re-installed GRUB with a configuration that simply booted into Windows, but I didn’t trust GRUB to be able to install its configuration files into an NTFS parition without trashing the partition. Enter the Super GRUB Disk.

The Super GRUB Disk is a nifty boot disk that makes it easer for a novice user to recover a system or experiment with GRUB without inadvertently rendering the system unbootable. Navigating the basic menus for booting a Windows partition gave me what I needed to get my system up and running. Using Super GRUB Disk version 0.9766 (baed on GRUB 0.97-os.1) the menu sequence was:

1. Choose language & NO HELP
2. <Language> Boot Disk (for me: English)
3. Windows
4. Boot from 2nd partition (Laptop)

Being a Dell, the first partition on my system is the Dell Utility partition and the second is the active NTFS partition, so this option was exactly what I needed. There are also options to boot from other hard disks, and to, of course, install the Windows bootloader (the equivalent of fdisk /mbr).

More information about the various options is available from the Choose language & HELP menu option, and from Herman’s Super Grub Disk Documentation, an excellent reference.

   export TERM=xterm-256color

To test, execute M-x list-colors-display in emacs.

On MacOS X one will need to install the ncurses package from macports. Unfortunately, the terminal emulator that ships with MacOS X – Apple’s Terminal.app – doesn’t support 256 colours; use iTerm.app instead.

EDIT: This ncurses package now appears in the Utils category.

Can't move '/cygdrive/c/xxx/trunk/.svn/tmp/entries'
to '/cygdrive/c/xxx/trunk/.svn/entries':
Permission denied

To resolve this, Tortoise SVN’s icon overlays may need to be disabled entirely as suggested here. While Tortoise SVN doesn’t have a Disable overlays checkbox, they may be effectly disabled as follows:

• <SecondaryClickContextMenu> > Tortoise SVN > Settings > Icon Overlays
• Ensure the checkout directory is included in the Exclude paths mask (I’ve taken to using c:* and c:*).

Others have suggested that it may not be necessary to disable Tortoise SVN’s overlays entirely, as long as the Show overlays only in explorer tickbox is ticked. This didn’t work for me; your kilometerage may vary.