How to copy from HFS+ to FAT32?

July 22, 2005 11:28 PM

A friend of mine is having trouble copying files from Mac HFS+ to a FAT32 drive, and I'm stumped.

A friend of mine is having trouble copying files from Mac HFS+ to a FAT32 drive, and I'm stumped.

He wrote me:

i'm having difficulties copying files from a mac-formatted hard drive to a fat32 formatted hard drive.

i've ordered a hard drive based MP3 player. i already had a had drive full of music, so all i needed to do was format my music drive in FAT32 so the player could work with it. i backed up the music files, formatted the drive, and now i'm having trouble copying the files back.

i know about the illegal DOS characters, so i renamed all the files that contained ? * " <>[]\/:;. i thought that would be the end of it, but now, when i try to copy, i get a message that says:

"the file 'icon
' could not be copied."

just like that, with the line break in the middle of the filename.
my drive contains hundreds of invisible "icon" files. do i have to destroy all custom icons to be able to copy? or can i somehow rename them? best of all, maybe there's a utility that can handle this whole mess for me?

This is on a PowerBook G4 running OS X. I thought I had heard of this before (in Classic Mac OS), but searching all the usual Mac support haunts turned up nothing, so I couldn't help him. Any thoughts?

posted by TPIRman to computers & internet (11 comments total)

I just tried dragging a random MP3 from my TiBook (OSX 10.3.9) to a 2GB FAT32 formatted CF card (via PCMCIA adapter). There were no complaints. Then I tried it with FireFox. Still no complaints.

A few thoughts:
1. OSX, like the Classic OSes has a concept of resource forks. These are essentially metadata associated with a file of the same name. Neither FAT32 nor other unix filesystems understand these. It could be that your friend has some extra resource data associated with some or all of his MP3s.

2. If this is how custom icons are associated with MP3s, he will need to get rid of them anyway. The mp3 player won't know what to do with them, so they can only take up space and possibly cause confusion.

Your friend should probably ignore the hidden "icon" files and just copy the raw MP3s.
posted by b1tr0t at 11:43 PM on July 22, 2005

hey b1tr0t,
i'm intimately familiar with TPIRman's friend (i.e. i'm him), so i can clear some of this up.
the invisible "icon" files are custom folder icons. they're not associated with the mp3's themselves (cover art is stored within the files).
it would be a shame to lose them; the player wouldn't mind the icon files, but (i hope) the custom icons would still be visible when i viewed the drive folder structure through my computer.
i guess i'd be willing to lose these custom icons if that's the solution to my problem, but i'd rather not. at any rate, i don't know how to ignore these files while copying.
posted by Silky Slim at 11:58 PM on July 22, 2005

try reformatting the drive as NTFS. As b1tr0t noted, FAT32 does not understand resource forks. A quick googling found this article at Ars (under Data Streams:)
posted by stupidcomputernickname at 12:18 AM on July 23, 2005

I thought Tiger has a method to preserve this metadata on filesystems that don't natively support it. Are you running 10.3 or 10.4?
posted by sbutler at 12:23 AM on July 23, 2005

Mac OS X has been able to deal with resource forks on volumes that don't support them natively for quite a while. The problem is not the resource fork or the Mac metadata.

The problem is invisible icon files, which is where the Finder used to store custom folder icons under Mac OS 9. I'm not sure they're even still used under Mac OS X. It should be pretty trivial to track them down and kill them on the source volume with a command-line find command.
posted by kindall at 1:00 AM on July 23, 2005

Under Jag, and probably Tiger, the HFS+ formatting includes at least one, and maybe a couple of items in every folder. One is called ".icon" and doesn't show up under OSX because of the initial dot making it invisible. You can do a search for all items in a particular folder that start with "." and drag all the results into the trash before trying to copy again. Good luck. Did this same thing my self about a year ago.
posted by squirrel at 1:12 AM on July 23, 2005

Yup, there's a CR (ascii 13) in the filename. I don't know why, but it's the standard name for that file. I also don't know how the file would be represented on a FAT filesystem — maybe you could mount the (mostly empty) FAT volume and apply an icon to a folder and see how it is represented on the disk? Then perhaps you could copy the icon\r files over to whatever FAT-compliant name they need to have. (Assuming the system on which you want the folder icons to show up is a Mac. If not, then I'm guessing the problem gets a lot more complicated, with image format conversion and whatnot.)
posted by hattifattener at 1:19 AM on July 23, 2005

(and if you just want to delete 'em all:

find /Volumes/wherever -type f -name 'icon^M' -exec rm {} \;

will do the trick. To enter the ^M, type control-V then control-M.)
posted by hattifattener at 1:23 AM on July 23, 2005

Btw, if you're not afraid of the command line, just use rm.
posted by squirrel at 1:31 AM on July 23, 2005

Um...not NTFS. Mac OS X only has read-only support. The only thing I can think of about the icon files is to try to copy a test folder over *without* the custom icon (temporarily remove it). And then *manually* add the custom icon and see if that even works. If you know a bit of command line, you could try copying the folders using the Terminal, to see if that'll ignore the icon files. Another thing to try is if you can, boot up in OS 9, and try copying then.
posted by edjusted at 1:38 AM on July 23, 2005

thanks all who replied.
finally solved this problem. as edjusted suggested, i tried pasting a custom icon to a folder in the fat32 volume, and it wasn't even possible. i also realized renaming the files is not an option, as the finder wouldn't recognize them by any other name.
doing anything under os9 wasn't an option either, as it apparently doesn't recognize fat32 volumes.
my only option became deleting all the .icon files using the method hattifattener suggested, but with a capital I in "Icon".
muchas gracias! solved!
posted by Silky Slim at 12:03 AM on July 25, 2005