Got Music on Your iPod You Need to Get Back Into iTunes? Here’s How.

I set up a new MacBook Pro several months back, but in moving things around, I managed to misplace some music. Most of my stuff is on a 160GB iPod Classic, and I wanted to synchronize the contents of the iPod with my iTunes library, recovering any tracks that were on the iPod but not in the library.

Out of the box, Apple doesn’t make this especially easy for you. Syncing within iTunes is strictly a one-way affair: what’s in your library replaces what’s on the iPod, precisely the opposite of what I want. Mounting the iPod on the desktop doesn’t help — you only get access to a shared file area, and the music is organized in a way calculated to keep you from figuring out where anything is.

Fortunately, there’s an easy solution, but it takes a few pieces to put together. This presumes that you’ve got your music in one folder on your computer, and you’re letting iTunes organize it for you (which it will do by artist).

First, you’re going to need FUSE for OS X, which allows you to create user-space file systems on OS X. Download the .dmg file — current version is 2.7.4 — and install it.

That sets you up to install iTunesFS. Download the iTunesFS 1.3.4 installer disk image from the downloads page, mount the .dmg and drag the iTunesFS app to your Applications folder.

Connect your iPod to an available USB port on your Mac, but don’t launch iTunes. Instead, launch the iTunesFS application. An “iTunesFS” icon will appear on your desktop, and opening it will reveal several folders, “Albums”, “Artists”, etc. You want the “Artists” folder.

Open another window and browse to your iTunes library folder — you can find out where this is under the “Advanced” tab in iTunes’ Preferences. You want the “Music” folder. (You’ll see why we want these files open in a moment.)

Now, open a terminal window. We’re going to use the rsync command to copy any files that exist in the “Artists” folder on the “iTunesFS” volume — a synthetic folder constructed by iTunesFS which mirrors the organization of the “Music” folder in iTunes’ library folder. Type the beginning of the command:

rsync -av --dry-run

Leave a trailing space at the end. Now, go to the “iTunesFS” window in Finder and drag the “Artists” folder on top of the Terminal window, and “drop” it there. The Terminal app will fill in the path to the folder you dropped, and the command will now look something like this:

rsync -av --dry-run /Volumes/iTunesFS/Artists

Add a trailing slash and a space at the end, so it looks like this:

rsync -av --dry-run /Volumes/iTunesFS/Artists/

Now, go back to Finder, and from the window that’s open to your iTunes library folder, drag and drop the “Music” folder onto the Terminal window. The command should now look something like this (it will vary depending on the names of your volumes, etc., obviously):

rsync -av --dry-run /Volumes/iTunesFS/Artists/ /Volumes/Vibranium/iTunes/Music

The --dry-run flag tells rsync to just simulate moving the files, this will give you a chance to check that things look reasonable first. The -av flags tell rsync to use “archive” mode, which means it will walk down the directories within the folder you specify recursively, and to provide “verbose” output. Execute the command, and it will provide a list of all the directories the command would create and the files it would move. If you’re satisfied with what you see (and you probably actually want to review it!), use the up-arrow to bring back your last command, edit out the --dry-run flag, and execute it again.

Pretty easy.

Stupid Problems Deserve Stupid Solutions

I recently got handed a pretty decent Vista-era Lenovo laptop, which on inspection, turned out to have no hard disk in it. I invested $30 in a 250GB SATA disk, and decided I’d have a go at setting up Kali Linux just to check it out.

I’m very impressed. It’s well-put-together and well-documented, there’s a good IRC channel on freenode, and it’s got most of what I want in a development workstation.

I did run into one little problem setting some things up, though. Apparently, prior version 1.0.8, lsb_release reported a codename of “n/a”, which causes the script to barf. That was reported as fixed, but it seems to have regressed in the latest version, 1.0.9a.

After fooling around with a couple of candidates to fix the problem — and does anyone know the right way to fix this…? Ugly details below — I broke down and just hacked the setup script.

The core problem is that lsb_release -c -s is returning “n/a”, and causing the script to decide that this isn’t a distro it knows how to support. Here’s the (stupid) fix.

First, pull down the setup script from the NodeJS site and save it to a file so we can patch it:

curl -sL >

Next, open in an editor and look for the following section:

check_alt "Linux Mint" "rebecca" "Ubuntu" "trusty"
check_alt "Linux Mint" "qiana" "Ubuntu" "trusty"
check_alt "Linux Mint" "maya" "Ubuntu" "precise"
check_alt "elementaryOS" "luna" "Ubuntu" "precise"
check_alt "elementaryOS" "freya" "Ubuntu" "trusty"

Edit it to all a line to the end as follows:

check_alt "Linux Mint" "rebecca" "Ubuntu" "trusty"
check_alt "Linux Mint" "qiana" "Ubuntu" "trusty"
check_alt "Linux Mint" "maya" "Ubuntu" "precise"
check_alt "elementaryOS" "luna" "Ubuntu" "precise"
check_alt "elementaryOS" "freya" "Ubuntu" "trusty"
check_alt "Kali" "n/a" "Debian" "wheezy"

Now, pass the script to bash as intended. This will set up the repos correctly to get node.js and its dependencies as though you were running on a stock Debian “wheezy” system.

cat | bash -

It should complete without a problem. Now, you can install nodejs and npm:

apt-get install nodejs

Gory Details

I’m unclear on where the code name reported by lsb_release gets set up. A couple of candidates which didn’t work: attempting various edits to /etc/os-release didn’t help nor did modifications /etc/dpkg/origins/default which is an aliased for /etc/dpkg/origins/kali. Anyway, it worked, nodes and npm are in and check out.