5

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 that the file is in
      error occurred while adding "" to the archive
  • delete directory in finder
      error -43
  • in Python: os.unlink(os.listdir(u'.')[0])
      OSErrorNo 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 any more 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 number:

#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 number, but the normal find -inum inode_num -exec rm '{}' \; doesn't work. I think I have to use the clri now.

5
  • Why reformat? Is this file causing you any problems? Where is the file located? Have you tried posting to an Apple forum? Aug 4, 2010 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, 2010 at 21:14
  • Can you rename the file in Finder and then remove? support.apple.com/kb/TS2039 Aug 4, 2010 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, 2010 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, 2010 at 21:34

5 Answers 5

1

Try

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

Have you tried deleting the parent directory?

4
  • 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, 2010 at 21:15
  • any chance the file is locked open? can you check using lsof ?
    – bryan
    Aug 4, 2010 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, 2010 at 21:24
  • The file is not locked. I checked using lsof and rebooted.
    – SiggyF
    Aug 4, 2010 at 21:26
1

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

1
  • 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, 2010 at 21:18
1

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.

1

For me

find parent-folder -delete

solved the problem. Attention: This will delete the whole parent folder, of course!

4
  • I'm upvoting to counter the unexplained downvote. Granted, this might not be the best solution, and it might not work in all cases. These are reasons that this answer might seem less useful. However, it is a novel approach, which someone might not think of immediately, and so I think it is useful to think about as a potential alternative.
    – TOOGAM
    Nov 2, 2015 at 19:23
  • I didn’t downvote, but I have an issue with this answer: there’s no logical reason why it should work when the other things that were tried (rm *, delete the directory in finder, find . -type f -exec rm {} \;, running rm -r on the parent directory, etc.) didn’t work.  If the OP chimes in and says, “Yes, this worked for me, when nothing else did!”, then I may upvote it.  (But this seems unlikely; SiggyF has probably nuked the filesystem and/or thrown away the computer in the past five years.)  … (Cont’d) Nov 5, 2015 at 20:21
  • (Cont’d) …  If mainzelM comes back and says, “I tried every other solution suggested on this page, and none of them worked, and this one did”, then I may begin to take it seriously.  If somebody can explain why this answer should work when all the others failed, I may upvote it.  Lacking those things, all we know is that mainzelM had a problem (maybe not really the same as the OP’s) that was solved with a hand grenade (and he doesn’t even describe what his problem was), so I don’t consider this a good answer. Nov 5, 2015 at 20:21
  • The reason why -delete can work if the other approaches fail is that in this case the filename is not passed from one program to another but finddeletes the file itself, using an OS call. If you do rm * the shell passes the filename to rm and if the filename contains characters that cannot be passed as program argument, rmwill fail. Some for find ... -exec rm {} \;. And yes, it helped me in a similar situation.
    – mainzelM
    Nov 6, 2015 at 8:26
1

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

Nope, you've been thorough. It looks like there an issue with a part of the filesystem. You could repair it. Or you could think about what other fun you'd like to do. However, the simple thing is to repair it.

You may be rightfully reluctant to repair the filesystem: there is a very small, but existing, chance that the repair could happen catastrophically. The best way to protect yourself from that is to have all important data backed up. Make sure that your backups are in good shape before you repair the filesystem.

Then, start the repair. When you know what to do, sometimes you just need the guts to proceed. You may find that this is entirely resolved in under half a second. (Or maybe a bit longer if there's some overhead... 3 seconds.)

Note that playing with damaged data also presents possible risk of causing further filesystem problems, so if you're trying to be safe, then the safe thing is to perform the preliminary checking (which you already did) and then just take care of the problem (after verifying backups).

2
  • Frankly, I’m not sure this is really an answer either.  Beyond the trivially obvious advice to backup everything before doing anything drastic, it doesn’t add much to what has already been said. Nov 5, 2015 at 20:23
  • The main message is "that playing with damaged data also presents possible risk", so the correct process is to proceed, rather than sit around hoping to think of some way to get stronger confirmation. The basic implied question is, "What is the next step?", and I'm providing a definite answer along with a reason for that.
    – TOOGAM
    Nov 5, 2015 at 22:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .