special characters - Delete a file that "does not exist" with a strange name

After a memory error in my program, I am stuck with a file with a strange filename. It's proving quite resistant to all normal methods to remove files with strange names.

The filename is:

%8BUȅ҉%95d%F8%FF%FF\x0f%8E%8F%FD%FF%FF%8B%B5T%F8%FF%FF%8B%85\%F8%FF%FF\x03%85x%F8%FF%FF%8B%95D%F8%FF%FF%8B%BD%9C%F8%FF%FF%8D\x04%86%8B%B5@%F8%FF%FF%89%85%90%F8%FF%FF%8B%85X%F8%FF%FF\x03%85%9C%F8%FF%FF%C1%E7\x02%8B%8Dx

I tried the following:

• rm * -> "No such file or directory"
• rm -- filename -> "No such file or directory"
• rm "filename" -> "No such file or directory"
• ls -i to get the inode number -> "No such file or directory"
• stat filename -> "No such file or directory"
• zip the directory where the file is in -> error occured while adding "" to the archive.
• delete directory in finder -> error -43
• in python: os.unlink(os.listdir(u'.')[0]) -> OSError No such file or directory
• find . -type f -exec rm {} \; -> "No such file or directory"
• checked for locks on the file with lsof -> no locks

All these attempts result in a file (long filename here) not found error, or error -43. Even the ls -i.

I couldn't find anymore options, so before reformatting or repairing my filesystem (fsck might help) I thought maybe there is something I missed.

I wrote this small c program to get the inode:

#include <stdio.h>
#include <stddef.h>
#include <sys/types.h>

int main(void) 
{
  DIR *dp;
  struct dirent *ep;

  dp = opendir ("./");
  if (dp != NULL)
    {
      while (ep = readdir (dp)) {
    printf("d_ino=%ld, ", (unsigned long) ep->d_ino);
    printf("d_name=%s.\n", ep->d_name);
      }
      (void) closedir (dp);
    }
  else
    perror ("Couldn't open the directory");

  return 0;
}

That works. I now have the inode, but the normal find -inum inode -exec rm '{}' \; doesn't work. I think I have to use the clri now.

Try

find . -type f -exec rm {} \;

Have you tried deleting the parent directory?

I usually open the enclosing folder in emacs dired mode, and then mark and delete.

Assuming that the file system is something other than JHFS+

Symptoms may be indicative of a normalisation issue.

In the ZEVO support forum, NFD: normalization=formD (normalisation form D) includes a partial transcript from panel discussion at the 2012 Illumos ZFS Day:

… subtle bugs that, I feel like no-one else would appreciate my pain. Like in the Unicode space there's actually two different ways to store, several characters – like an é on the Mac traditionally is stored as an e and an ´ character. When it's rendered they composite them.

On any other platform … store composite characters … one click, one character.

So on the Mac, without intervention, you can get into some nasty problems because the Finder stores it one way, Terminal chose a different way. So you can actually go into the Finder and create a directory – café – then go into the Terminal and

touch café

then you have two objects – you have a directory and a file with exactly the same name, which is, it leads to all kinds of … (!) … it looks the same but unlike … where you have differentiator, there's nothing, it's like, and in the Finder, depending on the Finder view you get different experiences. Sometimes you see two folders, sometimes you see a folder and a file, sometimes you see one folder. It's like, it's bizarre. So unfortunately …

… there's a formD-explicit setting so, on the Mac we highly recommend and in fact that's the default, you should use formD so then that problem, you can't do that – when you do the touch it'll actually map it back to the correct way.

You pay a little bit of an overhead but you can keep your sanity. It's crazy to have different stacks using different variants of the encoding.

– http://www.ustream.tv/recorded/25862520 around 00:10:33 on the timeline.