Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On my external hard drive are two directories, Fun. and Complex_, where that _ is a whitespace. I cannot empty from my trash or remove them with rm -rf and I want to. Neither show up in Finder on OSX, and I don't remember if they showed up in dolphin on linux. But they do show up in bash.

rm and mv returns No such file or directory. Containing folders can be moved and bring the special directories with them but they cannot be deleted.

Why can ls detect the files but rm and mv can't? How can I fix them? I am using \_on the complex file. (_ is whitespace).


The characters must not be the problem. I made "test." and "test " and I had no trouble removing them using quotes. But these dirs still cannot be removed. There must be something very low level wrong with the actual files themselves

sagan:Math ptwales$ ls
sagan:Math ptwales$ ls -i
ls: Complex : No such file or directory
sagan:Math ptwales$ ls -idF *
ls: Complex : No such file or directory
sagan:Math ptwales$ find . -name * -print0
find: ./Complex : No such file or directory
sagan:Math ptwales$ 

Same results with Fun. I'm guessing that the parent dir's have links to the files and know their names but files just don't exist or are corrupted somehow.

The external drive is in exFAT format. Would that be relevant?

share|improve this question
This looks like a corrupted filesystem or a buggy filesystem implementation. You tagged the question osx, linux and unix. On which systems did you try to access the files? Were the results different? Did you try to access the files on Windows with exFAT support (see my partial answer)? – pabouk Sep 27 '13 at 12:26
I created the files on linux on an ext4 partition then backed them up onto the exFAT. I remember I had this problem deleting it on the ext4 system, but I can't check for sure. The files aren't there now because I've repartition that drive since. Right now it's being accessed from OSX. I can try from a friend's windows setup, or boot from a debian thumb drive but the liveISO might not have exFat support installed. – cheezsteak Sep 28 '13 at 4:40
"The external drive is in exFAT format. Would that be relevant?" I would say it definitely can be, as the FAT family of file systems treats file names very differently from the file systems normally used on Unix-like systems. – Michael Kjörling Sep 29 '13 at 16:46

rm and mv can also detect the directories just fine, but it you type: rm file then the shell will ignore the whitespace.

There are a few things you can do to work around this. The easiest is to encapsulate the filename in quotes. Another solution is to escape the special char, e.g. with a backslash


touch "testfile "

host:/home/username/test>ls -al
total 12
drwx------   2 hennes  users  4096 Sep 26 02:44 .
drwxr-xr-x  34 hennes  users  8192 Sep 26 01:39 ..
-rw-------   1 hennes  users     0 Sep 26 02:44 testfile

Now to delete them, either:

rm "testfile ", or

rm testfile\ (please notice the whitespace after the backslash)

As for filenames ending in a dot. I can not reproduce the problem. Are you sure it ends in a dot and not in some other special char?

toad:/home/hennes/test>bash --version
GNU bash, version 4.1.10(1)-release (amd64-portbld-freebsd7.3)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

toad:/home/hennes/test>touch Fun.


toad:/home/hennes/test>rm Fun.

If it is another char than a dot then read up on the Internal file separator in bash. You can set it to something else, or just use commands sunch as find with -print0. (Example find /path/to/search-name 'SomeFilePattern*' -print0 | some_command)

share|improve this answer
This works with other testing directories but not those. The trailing characters must not be the issue here. – cheezsteak Sep 26 '13 at 17:17
Does ls -B show anything? ( -B Force printing of non-printable characters (as defined by ctype(3) and current locale settings) in file names as \xxx, where xxx is the numeric value of the character in octal. ) – Hennes Sep 26 '13 at 17:50
ls -B "Complex " and Fun. both turn up no such file or directory. I moving towards that there must be some exFAT file corruption maybe caused by the filenames but the file names aren't the problem now. – cheezsteak Sep 30 '13 at 15:29

I wrote up an answer about this to a rather similar question on Server Fault. The premise is slightly different but largely the same answer works.

You can combine ls -i (or stat which also prints the inode number) and find -inum. This works well for a small number of files, where for some reason direct wildcard globbing is undesired. The below example is adapted to directories, whereas the answer on Server Fault deals with files, but the principle is the same: using the inode number to identify the directory entry to do something with.

For example:

~$ ls -idF myweirddir
183435818 myweirddir/
~$ find . -inum 183435818 -exec mv -v '{}' 'delete-me' ';'
`./myweirddir' -> `./delete-me'
~$ ls -lA delete-me/
... check the contents ...
~$ rm -rf delete-me

This answer is also over on Server Fault, with minor differences and an alternative variant with direct process substitution using find and stat which probably isn't really applicable in your situation. If you like the answer here, consider upvoting on Server Fault as well.

share|improve this answer
I can't get the inode number of the files. Perhaps the files actually don't exist and the problem is with the parent directory thinking they do? – cheezsteak Sep 26 '13 at 17:18

This looks like a corrupted filesystem or a buggy filesystem implementation.

Unfortunately the exFAT filesystem is poorly supported on non-Microsoft systems. If you have ability to use a different filesystem, please consider it.

Please check the filesystem integrity. On Linux you can check the exFAT integrity by running exfatfsck. Unfortunately this utility will not be able to repair the filesystem. On Windows (XP with update KB955704, Vista SP1 or newer) you can use chkdsk which is able both to check and repair the filesystem.

share|improve this answer

When there is a file with some weird name that you can't type in, you can use bash select feature:

select f in * .*; do rm -i $f; done
share|improve this answer
If you don't quote $f, that's not going to work with all sorts of file names. – slhck Sep 26 '13 at 9:10
(1) This will ask about every file in the directory, which may or may not be what the OP wants. (2) rm -i doesn't work on directories, which the OP specifically asks about. (3) As @slhck says, quoting of $f, especially considering that the OP's very problem is exotic characters in the names. – Michael Kjörling Sep 26 '13 at 9:10

Your Answer


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.