Out, out, damned misnamed Mac file!

July 11, 2010 9:29 PM

I've got a niggling problem with an undeletable file in the trash of an external drive. I'm running Mac OS X 10.5.8.

The file in in a folder called 'Recovered files' and the file name (obviously invalid) is '␀␀␀õ␀␀.␀␀' with a modify date of 12/31/1903. Zero KB and the kind is listed as 'Alias'. It's in the /.Trashes/501 directory of the drive in question. When the drive is connected, the desktop Trash icon shows something to be deleted, but emptying the desktop trash has no effect (except the sound effect).

Not that big of a deal, but how do I get rid of it?

posted by DandyRandy to Computers & Internet (22 answers total)

you probably already tried this (hopefully!) but a quick reboot often clears up problems with undeletable items in the trash for me. so does stupid hoopjumping like pulling it out of the trash, renaming it, then trashing it again...

but you probably already tried this!
posted by messiahwannabe at 9:43 PM on July 11, 2010

rm -rf /\.Trashes/501
posted by pompomtom at 9:47 PM on July 11, 2010

Sorry, on re-read, that should probably be:


sudo rm -rf /Volumes/$DRIVENAME/\.Trashes/501

(adding in sudo, just to be sure...)
posted by pompomtom at 9:53 PM on July 11, 2010

If you're not familiar with Terminal.app, it's in:
/Applications/Utilities/Terminal.app

And once it opens, type what pompomtom wrote.
posted by jragon at 10:11 PM on July 11, 2010

This page is essential for such problems.
posted by TheRaven at 12:30 AM on July 12, 2010

Response by poster: Okay, I tried pompomtom's suggestion, and here's what I got:

rm: /Volumes/ITUNES/.Trashes/501/Recovered files/\004␀␀␀õ\001␀␀.\024␀␀: File name too long
rm: /Volumes/ITUNES/.Trashes/501/Recovered files: Directory not empty
rm: /Volumes/ITUNES/.Trashes/501: Directory not empty

By the way, attempting to rename the file results in an 'unexpected error' (code -43). Messiahwannabe's suggestion: dragging the folder out of the trash copies the folder but not the file, and the file can't be dragged out either way.
posted by DandyRandy at 12:33 AM on July 12, 2010

Try this, all of which is on a command line, lines beginning '#' are commentary. Press RETURN at the and of each line

cd /Volumes/ITUNES/.Trashes/501

# should not produce errors, if so we will need a slightly more complicated sequence,
# lets continue

sudo ls -al

# should list 3 things, one called '.', one called '..' and the erroneous file in question
# rename to cope with the filename too long bug, if there more than 3 this won't work

# 1) try this first, SP and TAB are the space and tab characters

sudo SP mv SP TAB foo

# Should come out as sudo mv funny_file_name foo

# 2) otherwise try this

sudo mv * foo

# to change it's name and then delete

sudo rm -rf foo
posted by epo at 2:22 AM on July 12, 2010

That filename is in 8.3 format, which suggests to me that your external drive is formatted with one of the Windows-compatible filesystems (FAT or FAT16 or FAT32). If that's the case, you may have more luck using a Windows box to delete the file than trying to do so on your Mac.

This is because Windows, unlike Unix, does wildcard matching inside its filesystem calls rather than having the shell do them and then pass expanded filenames to the filesystem API. So on Windows you should be able to plug in the drive, open a cmd shell, and type something like

F: (use whatever drive letter Windows assigns when you plug in the drive)
cd \.Trashes\501
del *.*

The Windows command interpreter will actually hand off the *.* wildcard pattern to the del command, which will pass it through to the filesystem API for processing. By contrast, typing rm * into a Unix shell causes the shell itself to expand the *, then insert the resulting filenames into the command line passed to the rm command. And since the filename contains NUL characters, and since NUL characters are used as string terminators in C programs, and since command line parameters get passed as C strings, rm will never see the whole file name.
posted by flabdablet at 4:53 AM on July 12, 2010

Sorry, that Windows cmd sequence should have been

F:
cd "\.Trashes\501\Recovered files"
del *.*

posted by flabdablet at 4:55 AM on July 12, 2010

rm: /Volumes/ITUNES/.Trashes/501: Directory not empty

Make that:

sudo rm -r /Volumes/ITUNES/.Trashes/501

Note the extra "-r" in there - it means "recursive", as in delete this-and-everything-in-it
posted by DreamerFi at 7:14 AM on July 12, 2010

DreamerFi, pompomtom's original suggestion already had "-rf" options, which is "recursive, force", and it already failed to remove the bogus file. I'm pretty sure this is because the filename includes NUL characters (bytes with a value of zero), which means it can't be passed in its entirety to any internal library routine that accepts a file or path name as a C string, and that rm -r will simply be enumerating the contents of any directory it wants to delete and then doing just that for all the resulting filenames.

In contrast, the DOS/Windows DEL command uses a Windows API that can work directly with filenames containing wildcards, and should be able to delete this bogus file without its broken name ever getting anywhere near a C string.

If I had to use a *nix box to do the job, I'd be unmounting the filesystem, opening up the block device in a hex editor, searching for those eleven gibberish bytes, replacing them with XXXXXXXXXXX, then remounting the file system and doing rm /Volumes/ITUNES/.Trashes/501/Recovered files/XXXXXXXX.XXX but that's probably riskier than the OP would countenance.

Another option would be to use an automated file system checking tool to get rid of the bogus filename characters. I know Linux has dosfsck which can do this; is there a BSD equivalent?
posted by flabdablet at 8:01 AM on July 12, 2010

Have you tried holding down the Option key while clicking on "Empty Trash?" It does a force on the action.
posted by mikeh at 8:04 AM on July 12, 2010

Copy everything interesting off of the drive. Reformat the SOB. Move the files back.

Problem solved.

Alternatively, I've had luck removing undeletable files in various operating systems by accessing the drive with another OS - try an Ubuntu live CD or plug the thing into a Windows box if it isn't HFS formatted.
posted by caution live frogs at 1:31 PM on July 12, 2010

Try ls -il to get the file's inode number, then

find /Volumes/ITUNES/.Trashes -inum inode_number -exec rm -i {} \;

posted by nicwolff at 3:45 PM on July 12, 2010

It looks like you may have some illegal characters in a filename. That's bad. Did you run Disk Utility on the drive and try to clean it up first? I'm assuming it's on an HFS+ (mac) drive. If it's on a DOS drive, you'll need to resort to DOS tools to clean it up.
posted by chairface at 4:25 PM on July 12, 2010

nicwolff, find will also end up passing the pathname to rm as a C string, so that probably won't work any better than just doing it the straightforward way with the shell.
posted by flabdablet at 6:31 PM on July 12, 2010

Response by poster: I've now got the external drive connected to an XP machine (it is indeed in FAT32 format). I tried flabdablet's suggestion with no success. It seemed to go through the motions, but the file remains. Attempting to rename the file fails.

So if you have any DOS-type suggestions, I'm ready for 'em.
posted by DandyRandy at 8:23 PM on July 12, 2010

Hm, that's probably right. OK, try this: ls -li to get the inode of the bad file. Then type df to get the name in /dev of the volume it's on (e.g. my HD is /dev/disk0s2).

Boot from an OS X install DVD, holding down ⌘ and "s" to enter single-user command-line mode. Type

umount /dev/whatever

to unmount the volume, then

clri /dev/whatever inode-number

to zero out the inode, and then

fsck /dev/whatever

to repair the filesystem and reclaim the inode. Then, just reboot normally.
posted by nicwolff at 8:29 PM on July 12, 2010

Oh, clri probably only works on HFS file systems. Good luck with FAT and DOS...
posted by nicwolff at 8:30 PM on July 12, 2010

Best answer: OK, if you've got access to an XP box then you can use XP's filesystem check tools. Open My Computer, right-click on the drive and select Properties. Click the Tools tab, then the Check Now button, then follow your nose.
posted by flabdablet at 8:39 PM on July 12, 2010

Response by poster: In this case, under these circumstances, flabdablet gets my undying friendship. Although I will take note of all the other suggestions for future reference, the damned file is now out, out. Thanks so much, eveyone!
posted by DandyRandy at 8:50 PM on July 12, 2010

Yeah, nicwolff, FAT filesystems don't actually have inodes. The kind of metadata that an inode-based filesystem would put in the inode (e.g. file size and access modes) goes in the directory entry in a FAT system, along with the filename (FAT systems have no concept of hard links) and the cluster number of the file's first disk cluster. A central File Allocation Table, indexed by cluster number, contains a linked list of cluster numbers per file, plus a linked list of free clusters, plus a linked list of bad clusters - effectively combining the functions of inode pointer records and a free space bitmap. It's quite conceptually elegant, but not very robust.

Since the filename portion of this particular file's directory entry was full of illegal characters, it's a fair bet that its starting cluster number would also have been bogus; were it not for the fact that such bogosity is indicative of further filesystem corruption, simply deleting the directory entry should have been enough. Unfortunately, the NUL bytes embedded in the filename conspired with the C string representation convention to make that very inconvenient to do. Fortunately, the DOS file naming rules make those bytes illegal in filenames, so the entry was treated as erroneous by the file system error check.
posted by flabdablet at 9:55 PM on July 12, 2010