I've been watching everyone thrash around on this for a bit, and have a couple of suggestions: (1) Is the original poster sure that the volume isn't damaaged? I'd start up in single user mode and run fsck before continuing. (2) I suspect that the problem is Unicode. Most C/Perl/whatever programs are going to be using the C interfaces to the BSD file services. There are some subtle complications between that layer, which works with UNIX paths as C strings, and the Carbon layer, which uses Unicode, where the HFS filesystem is actually implemented. For instance, there are Unicode character sequences which can't be preserved through translation, not even using UTF-8. That is to say, OriginalUnicode->UTF-8->Unicode != OriginalUnicode. If that assumption is true, there are no UNIX level tools that are going to let you delete this file. Heck, there probably aren't any UNIX level tools that can even tell you what its exact name is. Note that this is not the first time this has happened. I filed a bug against OS 10.1 where a StuffIt archive was unpacked on OS X creating two files named (I kid you not) "." and "..". These were impossible to delete in OS X. What you need is a Carbon application to delete this file. My suggestion would be to reverse the process. You've got an archive that created this filename -- use StuffIt or something to delete it. Select the enclosing folder and tell StuffIt to create an archive and delete the original. My guess is that StuffIt will use the Carbon APIs, get the Unicode version of the filename (or, more likely, its FSRef), and delete it with no muss or fuss. -- James Bucanek <mailto:privatereply at gloaming.com>