Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
Why reformat? Is this file causing you any problems? Where is the file located? Have you tried posting to an Apple forum? –  FrustratedWithFormsDesigner Aug 4 '10 at 20:56
    
Does ls -i list the file? If yes, but you can't delete it based on the inode, it sounds like the filesystem is damaged. –  Bobby Aug 4 '10 at 21:14
    
Can you rename the file in Finder and then remove? support.apple.com/kb/TS2039 –  Doug Harris Aug 4 '10 at 21:28
    
Thanks, yes I tried to remove it in finder and using mv. Finder gives the -43 error and mv gives the error "file not found". –  SiggyF Aug 4 '10 at 21:30
1  
The ls -i, ls -i filename and ls -i * all give the error 'file not found'. I moved the directory where the file is in to the trash, but now the non-empty trash can gives me an untidy feeling. So I'll keep trying to clean it up. I posted it here first. –  SiggyF Aug 4 '10 at 21:34

3 Answers 3

Try

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

Have you tried deleting the parent directory?

share|improve this answer
1  
Thanks for the suggestions. The find gives a "No such file or directory" on the find . -type f. I tried rm -r of the parent and removing the directory in finder. It won't clean the trash when I put this file in it. It says: operation cannot be completed because the item "myusername" is in use. –  SiggyF Aug 4 '10 at 21:15
    
any chance the file is locked open? can you check using lsof ? –  bryan Aug 4 '10 at 21:21
    
I don't think so. You mean like mv filename /dev/null ? I don't think that works for any file. –  SiggyF Aug 4 '10 at 21:24
    
The file is not locked. I checked using lsof and rebooted. –  SiggyF Aug 4 '10 at 21:26

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

share|improve this answer
1  
Thanks for the suggestion. Starting dired in this directory gives me the error: "Listing directory failed but 'access-file' worked.". I also tried it with aquamacs, same error. –  SiggyF Aug 4 '10 at 21:18

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.