Abstract

A friend of mine wanted to copy some files from an iTunes™ playlist to an external drive, but iTunes™ wouldn't allow her to simply let these files being dragged to the intended destination folder in Finder™. She asked me what she could do about it.

I thought about it for a minute, knowing that it wouldn't work with iTunes™ alone - but I realized that it's probably simple to code a solution. Even better than having a separate standalone application for it, I figured I could write a new FUSE file system - making use of the excellent MacFUSE project!

Enter iTunesFS, a FUSEOFS based file system for your Mac, which makes all your iTunes™ playlists available as folders in Finder™! And - not only that - as you can see in the screenshot below, version 1.1 adds support for iPod™s in the very same manner!

Now you can easily copy content of your iTunes™ library and your iPod™s in Finder™ or the Terminal - ideal for, err, backing up specific content. Whatever.

As noted by Peter da Silva, the above statement isn't really true for current (7.x) iTunes versions. In fact, these versions allow you to drag files from playlists to mounted filesystems, effectively making them copyable via drag and drop. However, this still isn't true for mounted iPods within iTunes. Also, the playlist ordering won't be preserved by doing so, thus using iTunesFS still has quite a lot of advantages.

History

• 2009-03-30: I'm currently lacking time for iTunesFS development, so there'll be no updates anytime soon (IMO it's feature complete, thus no need for updates anyways). I had a brief look at Dokan on Windows which looks promising, but unfortunately it's not in the shape to begin a port of iTunesFS for it, yet. Dokan has C# bindings which is pretty nifty, given that a mechanism similar to Objective-C categories (called extension methods) was introduced in C# 3.0. If I were to port iTunesFS to Windows, I'd do a rewrite in C# 3.0 or above and use extension methods for the FUSEOFS approach. In C# 4.0, one could even use duck typing via the new dynamic pseudo type to make this even nicer and more similar to the Objective-C approach.

• While reviewing some code, I noticed that I totally forgot implementing hierarchical playlists, which are possible in later iTunes versions. It was pretty easy (10 minutes work) to implement, so grab version 1.1.10 (released 2009-01-30) while it's hot. ;-)

  Please note that I've added a new entry in the cheap tricks section which explains how to share the iTunesFS file system via Apache/WebDAV.

• Thanks to code contributed by Frederik Seiffert of algoriddim, version 1.1.9, released 2009-01-29, sports a new flawless iTunes library detection.

• Version 1.1.8, released 2009-01-28, fixes a bug introduced in 1.1.7 release. The allow_other FUSE option, required for sharing the iTunesFS filesystem via Apache/WebDAV, is disabled by default in 1.1.8 but can be triggered via the new FUSEOptionAllowOther default.

• Version 1.1.7 was released 2009-01-25. It should have been released in January 2008, but unfortunately my new contracting work stalled every personal software project until now (and will probably continue to do so for several years). This version fixes another set of Leopard issues and adds support for burn folders in Finder - now you can directly burn your playlists from Finder, without the need to do this in iTunes™ - thanks go to Dan Villiom Podlaski Christiansen for contributing this addition. Starting with this version, a freshly mounted iTunes file system will automatically open a Finder™ window. Both changes can be controlled via new user defaults. Worth noting: this version fixes a long standing Unicode encoding problem which lead to some files not being able to be copied by the Finder! Users with tracks bearing accented characters (i.e. Brazilian songs) will be delighted to hear this most likely! ;-)

  This new version requires MacFUSE core 2.x!

  Mac OS X 10.4 (Tiger) support has been dropped in 1.1.7. I don't have a proper Tiger system available for testing and thus cannot guarantee that 1.1.7 will work on Tiger. If someone wants to step up and provide this support for Tiger, I'll reenable the build for Tiger.

• Version 1.1.6, released 2007-12-31, fixes the "not visible in Finder's sidebar" problem on Leopard. Also, there's a new NoITunes default which, if set, prevents the iTunes library from being displayed.
• Version 1.1.5, released 2007-10-30, sports support for Jailbroken iPods and iPhones (tested with an iPod Touch, thanks to Terrance Lam). For users who mount their iPhones and iPods via MacFusion, set the new iPodMountPoints user default to the appropriate mount point.

  Also new in this release is the existence of a new Compilations group, thanks to code contributed by Mark Wallis.

• Version 1.1.4 saw the light of day at 2007-07-03. This version sports formatters which enable you to customize the formatting of track names displayed in Albums and Playlists in a very generic way. If you don't like the playlist index as a prefix you can easily redefine the formatter to not include it, and so on.
• Version 1.1.3 was released 2007-06-14. This version introduces "categories", which means that from now on you can browse by Artists and Albums in addition to the playlists. The file system hierarchy will be expanded, accordingly and has been localized for this purpose in German, French, Italian, Spanish and Japanese. If you don't need this feature, which is enabled by default, you can turn it off using a default.

  One more thing! ;-) This version has also been ported to GNUstep - this means that from now on you can write FUSE based file systems in Objective-C on any platform which is supported by GNUstep!

• Version 1.1.2 was released 2007-05-31. It fixes a bug that prevented tracks from being accessible which had a question mark ("?") somewhere in their path name. Also, file metadata is now computed from the libraries' contents. Libraries having just one playlist (i.e. Shuffle devices) do omit this playlist and instead display all tracks at once. Last but not least, added the ability of returning symbolic links instead of "faking" the presence of files. People using iTunesFS in association with shell scripts might prefer that option.
• Version 1.1.1 was released 2007-05-29. It fixes a bug that prevented iPods from unmounting. Also, iTunesFS can be told not to scan for iPods at all. In case no iPod is found, the file system hierarchy will be missing the libraries entry, which is much more convenient in these cases I guess.
• Version 1.1.0 was released 2007-05-24. It adds the not-so-long anticipated support for iPod™s!
• Version 1.0.4 was released 2007-05-23. It currently supports a single iTunes™ library only, but there will be support for iPods in the near future I guess! ;-)

Download

IMPORTANT! Before you can start using iTunesFS, you need to install the appropriate MacFUSE Core package!

Date	Version	MacOS X	File	Required MacFUSE Core version
2009-01-30	1.1.10	10.5 (Universal 32/64)	iTunesFS-1.1.10.dmg	MacFUSE-2.0.3,2.dmg
2007-12-31	1.1.6	10.4 + 10.5 (Universal 32)	iTunesFS-1.1.6.dmg	MacFUSE-Core-10.4-1.1.0.dmg (MacOS X 10.4) OR MacFUSE-Core-10.5-1.1.1.dmg (MacOS X 10.5)

Also, the whole sourcecode is available from Mulle kybernetiK's Subversion Repository.

svn co http://svn.mulle-kybernetik.com/iTunesFS/trunk iTunesFS

See license for details. Modifications and suggestions welcome!

Having Trouble?

First of all - please note that it's normal for iTunesFS not to bounce in your dock! This is intended behaviour, as iTunesFS is not really an ordinary Desktop application with a menu, but rather a file system (you can tell that by looking at the screenshot in case you still have doubts).

If you don't see the iTunesFS Volume appear in Finder shortly after you started the application, something unexpected has happened…

Popular reasons that cause iTunesFS to fail are:

• iTunesFS expects the iTunes Music Library.xml file to be in the standard default place, that is ~/Music/iTunes/iTunes Music Library.xml (where ~ designates your home directory). If you happen to have changed that location, all is not lost - fancy iTunesFS sports a nifty user default just for that case! ;-) Open Terminal.app and type the following:

  defaults write com.mulle-kybernetik.znek.iTunesFS Library COMPLETE_QUALIFIED_PATH_TO_YOUR_ITUNES_XML_FILE

  Make sure to apply proper quoting/escaping in a shell, i.e. use backslash escapes for spaces and the like. For setting the path to the default library file in a proper manner, you would have to type:

  defaults write com.mulle-kybernetik.znek.iTunesFS Library ~/Music/iTunes/iTunes\ Music\ Library.xml

• You need MacFUSE Core from the link above! Using a Fink package won't work (out of the box).

Sharing the iTunesFS filesystem via Samba doesn't work. I have tried to debug the issue in the past and came to the conclusion, that the problem is buried deep in FUSE/Samba interaction. If anybody can shed any light on this issue any hints are appreciated. For the time being, resort to sharing iTunesFS via Apache.

Cheap tricks

• (since version 1.1.1): If you don't want iTunesFS to look for iPods at all, type the following in a Terminal:

  defaults write com.mulle-kybernetik.znek.iTunesFS NoIPods -bool YES

• (since version 1.1.2): create symbolic links rather than fake files:

  defaults write com.mulle-kybernetik.znek.iTunesFS SymbolicLinks -bool YES

• (since version 1.1.3): browse using categories ("Albums", "Artists", "Playlists"):

  defaults write com.mulle-kybernetik.znek.iTunesFS UseCategories -bool YES

• (since version 1.1.4): format the displayed track names in a generic way:

  defaults write com.mulle-kybernetik.znek.iTunesFS AlbumsTrackFormat "'%(trackNumber#00) %(name).%(ext)'"
  defaults write com.mulle-kybernetik.znek.iTunesFS PlaylistsTrackFormat "'%(playlistNumber#000) %(name).%(ext.lowercaseString)'"

  Several things to note here:

  • Make sure to apply proper quoting in the shell!
  • The defaults are AlbumsTrackFormat and PlaylistsTrackFormat
  • For experienced users:
    The formatters are being applied via -valueForKeyPath: which means that anything in %() can be a complete KVC keyPath. The second example (above) utilizes this feature and guarantees, that the file extension (i.e. mp3) is in lower case.
  • As you can see above, numbers can be formatted via a number format… the separator character is #.
  • Interesting properties are:
  • name
  • album
  • artist
  • extension (you can also use ext as a convenience)
  • trackNumber
  • playlistNumber
  Example:
  

  defaults write com.mulle-kybernetik.znek.iTunesFS PlaylistsTrackFormat "'#%(trackNumber#00) %(name) (%(artist) - %(album)).%(ext)'"

  This will produce output similar to this:
  #05 Per Aspera Ad Astra (Moshcircus - Karma).m4a

• (since version 1.1.5): watch for iPods at the following mount points:

  defaults write com.mulle-kybernetik.znek.iTunesFS iPodMountPoints -array /Volumes/iPodTouch

  Replace /Volumes/iPodTouch with the real path to your iPod's mount point. Note that you can provide multiple values (in case you have an iPod Touch AND an iPhone ;-).

• (since version 1.1.6): If you don't want iTunesFS to show your iTunes library, type the following in a Terminal:

  defaults write com.mulle-kybernetik.znek.iTunesFS NoITunes -bool YES

• (since version 1.1.7): If you want have burn folders in Finder so you can quickly burn your playlists and such to CD/DVD:

  defaults write com.mulle-kybernetik.znek.iTunesFS UseBurnFoldersInFinder -bool YES

• (since version 1.1.7): If you don't want iTunesFS to automatically open a window in Finder after it's mounted:

  defaults write com.mulle-kybernetik.znek.iTunesFS AutoOpenInFinder -bool NO

• (since version 1.1.8): Set the allow_other FUSE option:

  defaults write com.mulle-kybernetik.znek.iTunesFS FUSEOptionAllowOther -bool YES

• Sharing the iTunesFS filesystem via Apache is pretty easy in itself, and it gets even better if you share it via WebDAV - this way, you can mount the exported filesystem on Windows as a webfolder, map it to a drive letter and so on. Make sure to enable WebDAV in /etc/apache2/httpd.conf and use something similar to the following rules somewhere in one of the config files:

  <Directory "/Volumes/iTunesFS/"> Options Indexes AllowOverride All Order allow,deny Allow from all </Directory> Alias /iTunesFS /Volumes/iTunesFS <Location /iTunesFS> Dav On </Location>

  You need to set the allow_other FUSE option for this to work properly, though.

Popular feature requests that I won't implement any time soon

• Q: Photo support?
  A: Photo support shouldn't be too hard, but it's nothing I'm personally interested in at the moment. It's not trivial, though, and would require a couple of hours for research and development.

Popular feature requests that I won't implement, ever.

• Q: Write support?
  A: Forget it. Writing isn't trivial. At least iTunes™ will want to write to the same database files concurrently, thus we'd need a way to tell iTunes™ to stop - and even to re-synchronize afterwards we have written our changes. Even if we could do that, how would we reorder entries in a playlist? By renaming the prefixing index manually? This is totally unusable in my opinion. iTunes™ is really great at managing the contents of your library and your iPod™s. The only thing that it doesn't allow you to do (probably by intention) is to easily copy content off your library or your iPods to a location YOU desire. iTunesFS fixes that "problem", nothing more and nothing less.

• Q: Make iTunesFS work with the Fink package?
  A: Create a symlink instead. iTunesFS links against /usr/local/lib/libfuse.0.dylib, so make sure it finds the version installed by Fink there - if you really must use the Fink version.

• Q: Is it possible to share the iTunes library to make it available on the local network (via Zeroconf/Bonjour)?
  A: Personally I don't have any interest in this feature while technically it's possible to do this with iTunesFS. However, there are several obstacles to overcome and it's pretty much non-trivial.

License