Long filenames on Windows cause troubles

A few weeks ago, I was forwarded a tech support email from a Windows XP user who couldn't unzip a few of our albums.

After way too much research, I found that Windows XP and Windows 7 both have problems (in different ways) with long filename paths. Not the file's length, mind you, but the total name of the entire path to get to a file, i.e.:

C:\Documents and Settings\Administrator\Desktop\Artistname\Albumname\MP3name.mp3

Specifically, there is a concept in Windows of the MAX_PATH variable, which is 260 characters, and which causes problems in different places.

• In Windows XP, you can't drag-and-drop files from a zip file to your desktop if the total filename length is over 260 characters. No problem unzipping though, if you right-click and choose "extract" or use winzip or 7zip. Just drag-and-drop doesn't work.

• In Windows 7, if you drop long filenames onto the recycle bin, you'll be told you can't because they're too long, and do you want to skip those files or cancel the drag-and-drop.

I really wanted to fix these problems, because when these things occur, people don't blame Microsoft, they blame Magnatune, and tell us that our ZIP files are broken, and I want my customers to be happy!

So... a new test at Magnatune now identifies if the total likely size of an unzipped file will be over 240 characters (I'm building 20 characters of safety margin in).

The two most common places to drop audio files is:

Your desktop:
C:\Documents and Settings\Administrator\Desktop

Your iTunes music directory:
c:\Users\Administrator\Music\iTunes\iTunes Media

Since the iTunes music directory is the longer name of the two, I'm adding up the total filename length of:

iTunes Directory \ + Artist name \ + Album name \ + MP3 name = total

and making sure that never goes over 240 characters.

There were about a dozen albums at Magnatune that had files that went over this limit. I've gone ahead and "fixed" those.

So... if you ever had trouble drag and dropping files out of a ZIP file on Windows, hopefully now you won't!

-john

Comments

[panzi]

The safety margin is a good idea, because e.g. under a german Windows installation it is not "Documents and Settings" but the even longer "Dokumente und Einstellungen". However, under new Windows versions (at least Windows 7+) both "C:\Documents and Settings" and "C:\Dokumente und Einstellungen" are just symbolic links to "C:\Users" and I think therefore do not count. Look at all these symlinks, it's crazy: http://imgur.com/pRMjt

[Nick]

Eugh, that's crazy. XP I can forgive as it's many many years old, but Windows 7 not allowing long filenames to be dragged to the recycle bin? Hilarious. Another in the long list of reasons I'm happy to have moved to Debian a long time ago.

[psywiped]

Nick it's a NTFS filesystem limitation so its going to stick around till we get something new.

[John]

Actually, it's a Win32 API limitation (not NTFS). Also, it's not a variable, because that would imply you can change it. It's a #define in WinDef.h.

Unicode enabled APIs can bypass it by using full paths prepended with "\\?\" and get up to 32k file names. Unfortunately, there's a lot of stuff that doesn't support it (including Explorer), mostly due to legacy software and clueless "software developers" that give the rest of us a bad name. (All those symlinks Panzi mentioned are there for the clueless who hard code things like "C:\Documents and Settings\All Users\" in their software, instead of asking the OS where it's really supposed to go.)