Problem with Music Files on USB Drives

I'm not sure how you managed to not have this problem before. You may have installed BlueHarvest which would prevent writing them. If you don't write the files with Finder, I think you can avoid it, but I'm not certain.

Before ejecting, run this command replacing volumeName with the name of your usb stick. If it has spaces in the name, enclose the full path in double quotes

dot_clean -m /Volumes/volumeName

elcpu wrote:

I erased the drive using Disk Utility and then copied the mp3s to the drive using Finder. Lo and behold the car then started to "say" that every other file was unplayable. I tried the stick on a music system at home, same issue, every other file unplayable. I then tried a different USB drive, same issue. Long story but the problem is that macOS places a duplicate named copy of every file in the USB drive with the prefix ._ and the extension .mp3 (even though they are not mp3s) and to make matters worse the files are hidden in macOS.

The Finder sees that the external drive does not use a Mac filesystem. It is trying to preserve some extended attributes that a Mac filesystem would maintain, by creating

• FOO.MP3 – the main file
• ._FOO.MP3 – the extended attribute file

The idea being that if you ever copy files back to the Mac, it can transparently combine the data from these two files, to preserve the extended attributes.

macOS is based on Unix, and adding a leading '.' (s a standard Unix convention for hiding a file from regular directory listings. The ._FOO.MP3 name represents an attempt to create a hidden file with a unique name that is easy to associate with the main file.

Unfortunately, other systems don't know about the Finder's "._" games, and may not even know about the Unix convention for hiding a file by starting its name with a "." They see the .MP3 suffix, conclude that the extended attribute files are MP3 files, and of course, then discover that these "MP3" files are hopelessly corrupt.

The same issue happens with preparing thumb drives and memory cards for use with HDTVs and digital picture frames. The ._*.JPG files look like corrupt JPG photos to many third-party devices.

The solution is to go into Terminal just before you eject a memory card or USB flash drive.

1. Go to that volume. (E.g., type cd and a space, then drag-and-drop the memory card or USB flash drive icon.)
2. Do a rm ._*.* to get rid of all files with a leading ._
3. Do a ls -a to identify any remaining files that begin with a .
4. Do a rm on any such files other than . or .. (in Unix, . means the current directory and .. is the parent directory)
5. In the Finder, eject the memory card or flash drive without doing anything else first.

For a MP3 or JPG file, you don't lose all that much by trashing the extended attributes file – even if you do decide to later copy the file back to the Mac.

For my 3D Printer, I created a Shortcut that I use to Clean & Eject the USB stick.

The code in the shell script:

args = ("$@")
if [[ $# -eq 0 ]]
	then args=("/Volumes/Prusa_Mini");
fi
for v in "${args[@]}"
do
	dot_clean -m "$v"
	diskutil eject "$v"
done

You can add a Shortcuts menu to the Status Menu area in the Menubar. You can also, ctrl-click on the drive and choose the Shortcut to clean and eject. Just change the path in the args= line to match your volume.

You can probably add lines to remove .DS_Store, .Trashes, and .Spotlight-V100, but if they don't cause any problems, probably leave alone.

For the checking part, if you just open the window and show hidden files (cmd-shift-. ), it won't write .DS_Store or the metadata (._) files. The metadata files only get written when you write the file.

You can delete the .DS_Store file and if you don't sort or do any other manipulate with the Finder, it should not write that back to the drive. It stores the information on how you want to display the folder in the Finder. If you don't alter the default view, it should not write another file.

You'll still have .Trashes and maybe a .Spotlight-V100.

I can understand the Spotlight issue. It should not affect anything. It will fail because it cannot read inside the directory.

The pathname error sounds strange. You should get a directory not found error.

I'll try to see if I can replicate that and figure out what is wrong. I think it is just reporting an error trying to get into some other sub-directory.

With the space, the command would be:

dot_clean -m "/Volumes/MINI 64/"