Rotten Trash in FileVault
For the last couple of weeks I had something in my trash that wouldn't delete. Whenever I emptied the trash, I got an error and had to skip the file in question. I checked Apple's knowledge base Article on the topic, but the suggestions in there didn't work for this case. Me using FileVault made the problem a bit more complicated... in the end logging in as root and mounting my home disk image from there solved the problem... for details see after the break.
Prehistory: At some point some items on my desktop started to behave erratically. The icons would disappear until I selected them. Move things around, the "haunted" items would revert to their position. Somehow I managed to copy the important stuff (using the Terminal) then move misbehaving items to the trash. Where most of them could be deleted, but one of them stubbornly resisted. In fact it was the empty hull of an application program, so in fact a folder with the suffix ".app". Trying to access the file from the Terminal resulted in "IO Errors".
Normally I'd now run fsck in single user mode (yeah, I'm that kind of Mac user), but since my home directory is in a "FileVault" (Apple's technology for an encrypted home directory - and yeah, I'm that kind of Mac user too), that wasn't so easy.
What I did then was to log in as root exclusively, mount the FileVault disk image of my home directory (which can be found in /Users/.username/username.sparseimage), then run a check/repair with "Disk Utility" on it. Mounting the disk image took a very long time on the "verify" step. Fine with me. "Disk Utility" didn't find anything to repair though... there went my theory. But given that I had a root shell at my hands, I went for a look in the .Trash folder in there. To my surprise, not only did I see the stubborn thing, there were also the other items that I thought I had managed to delete long ago. To my further surprise I succeeded in deleting everything with rm. Logging back in to my normal user (and a restart after a software update later), the things are still gone.
New theories: Either having the volume mounted, but not as a user home directory allowed the deletion of the files without some special function looking at .Trash intervening... or else the long "verify" step in the mounting process had actually fixed some file level errors. Spooky stuff.