Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I untarred a corrupt tar file, and managed to end up with some directory that I can not delete, If I try to delete it, it seems like it can not be found, but ls shows it's present, both with bash and with python I get similar behaviour, except right after I try to delete it with rm -rf, ls complains it can't find it, then it lists it (see below after rm -rf). The find command shows the file is present, but still I can't think of a way to delete it.
Here are my attempts:

Here you see both ls and find agree we have a directory,

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -print0  
./mikeaâcnt 

But I can't delete it:

rl]$ find -maxdepth 1 -type d -empty -print0 |  xargs -0 rm -f -v 
rm: cannot remove `./mikeaâ\302\201\302\204cnt': Is a directory
rl]$ ls
mikeaâ??cnt

I can cd to it though and it's empty:

rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ pwd
.../rl/mikeaâcnt


mikeaâ^Á^Äcnt]$ cd ../
rl]$ ls
mikeaâ??cnt

see below that is not a simple file but a directory, plus ls behaves funny after the rm -rf it says it can't find the file then lists it straight after:

rl]$ rm mikeaâ^Á^Äcnt/
rm: cannot remove `mikeaâ\302\201\302\204cnt/': Is a directory
rl]$ rm -rf  mikeaâ^Á^Äcnt/
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ 

So this is the attempt with python, the file is found, but the name is not usable as a name that can be deleted:

rl]$ python 
Python 2.6.6 (r266:84292, Jul 10 2013, 22:48:45) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import shutil
>>> os.listdir('.')
['mikea\xc3\xa2\xc2\x81\xc2\x84cnt']
>>> shutil.rmtree(os.listdir('.')[0] )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/shutil.py", line 204, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/usr/lib64/python2.6/shutil.py", line 202, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: 'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

even when I use tab completion the name it picks up is no usable:

rl]$ rm -rf mikeaâ^Á^Äcnt 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

using the name that python shows with bash I get this:

rl]$ rm -rf "mikea\xc3\xa2\xc2\x81\xc2\x84cnt"
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Is there anything I can do to get rid of this corrupt dir? The underlying filesystem (NFS) seems functional and no other problems are reported, and I have had no such problems until the corrupt tar file.

EDIT: Here is using find's own -exec option to call rm

rl]$ find -maxdepth 1 -type d -empty -exec rm -f {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

but the file is still there, (ls complains it can't find it, but then shows it anyway)

2nd EDIT:

rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

The behaviour is still unchanged, the file still present

3rd EDIT:

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} + 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

There seems to be more to the name than mikeaâcnt from looking at the output of the python attempt mikea\xc3\xa2\xc2\x81\xc2\x84cnt, and this screenshot:

ls output

4th EDIT: This is the attempt with a wild card:

rl]$ echo * 
mikeaâcnt
rl]$ echo mike* 
mikeaâcnt
rl]$ rm -rf mike*
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

and my locale:

rl]$  locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

5th Edit:

rl]$ ls -i 
ls: cannot access mikeaâcnt: No such file or directory
? mikeaâ??cnt

but also the behaviour has changed, now ls and cd do this:

rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt 
mikeaâcnt: No such file or directory.

This has happened after the attempts to delete, I'm thinking that it might be NFS issues as suggested in one of the answers here by vinc17.

6th EDIT: This is the output of lsof and ls -a

rl]$ /usr/sbin/lsof mikeaâ^Á^Äcnt lsof: status error on mikeaâ\xc2\x81\xc2\x84cnt: No such file or directory

above is wrong, here is the correct lsof invocation:(rl is the parent directory)

rl]$ /usr/sbin/lsof | grep mike | grep rl 
tcsh      11926   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14733   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14734   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14735   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14736   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
rl]$ 

rl]$ ls -a
ls: cannot access mikeaâcnt: No such file or directory
.  ..  mikeaâ??cnt

7th Edit: move wont work, (I tried it before all this, but I did not save the output), but it has the same problem as ls and rm with the file.

8th EDIT: this is using the hex chars as suggested:

 rl]$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a    mikea......cnt.
rl]$ rmdir $'mikea\6d69\6b65\61c3\a2c2\81c2\8463\6e74\0acnt' 
rmdir: failed to remove `mikea\006d69\006b651c3\a2c2\\81c2\\8463\006e74': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

9th Edit: for the stat command:

 rl]$ stat  mikeaâ^Á^Äcnt 
stat: cannot stat `mikeaâ\302\201\302\204cnt': No such file or directory
 rl]$

Its seems even more likely from all the output, there is a bug or other NFS misbehaviour as suggested in the comments.

Edit 10: This is strace output in a gist since its so large, its the output or these two commands:

strace -xx rmdir ./* | grep -e '-1 E'`
strace -xx -e trace=file ls -li`

https://gist.github.com/mikeatm/e07fa600747a4285e460

Edit 11: So before the above rmdir i noticed that i could cd into the directory, but after the rmdir i could not cd again, similar to yesterday. the . and .. files were present:

rl]$ ls
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ ls  -a
.  ..
mikeaâ^Á^Äcnt]$ cd ../

Final Edit: I saw a local admin over this and it was dealt with by logging on to the server itself and deleting from there. The explanation from them is that it could be a problem with character sets in the name being inappropriate.

share|improve this question
    
Is there a reason you're piping find's output to a different command instead of just using it's exec option? –  HalosGhost Jul 30 at 8:57
    
@HalosGhost there was no reason, see edit for added information on your question –  mike-m Jul 30 at 9:03
2  
As someone with very little experience with unix and linux, here's my idea: try renaming the directory to something without those symbols using mv. maybe you can delete it after that. Alternatively, you can try moving the directory to a deeper folder level (maybe with a wildcard) and then deleting the folder you've moved it to. –  Nate Kerkhofs Jul 30 at 12:51
4  
I suspect the directory only exists in memory on the client and is long gone on the server. Have you tried umounting it and mounting it again? Have you tried rebooting the client? Is it visible on other clients? –  kasperd Jul 30 at 13:46
6  
@mike-m It sounds like you've hit an NFS bug, probably in the NFS server. Either that or filesystem corruption on the server. I doubt you can really do anything else other than wait for the NFS server admin(s) to deal with it. –  derobert Jul 30 at 15:50

8 Answers 8

up vote 8 down vote accepted

The following excerpt from this essay potentially explains why that directory refuses to be deleted:

NFSv4 requires that all filenames be exchanged using UTF-8 over the wire. The NFSv4 specification, RFC 3530, says that filenames should be UTF-8 encoded in section 1.4.3: “In a slight departure, file and directory names are encoded with UTF-8 to deal with the basics of internationalization.” The same text is also found in the newer NFS 4.1 RFC (RFC 5661) section 1.7.3. The current Linux NFS client simply passes filenames straight through, without any conversion from the current locale to and from UTF-8. Using non-UTF-8 filenames could be a real problem on a system using a remote NFSv4 system; any NFS server that follows the NFS specification is supposed to reject non-UTF-8 filenames. So if you want to ensure that your files can actually be stored from a Linux client to an NFS server, you must currently use UTF-8 filenames. In other words, although some people think that Linux doesn’t force a particular character encoding on filenames, in practice it already requires UTF-8 encoding for filenames in certain cases.

UTF-8 is a longer-term approach. Systems have to support UTF-8 as well as the many older encodings, giving people time to switch to UTF-8. To use “UTF-8 everywhere”, all tools need to be updated to support UTF-8. Years ago, this was a big problem, but as of 2011 this is essentially a solved problem, and I think the trajectory is very clear for those few trailing systems.

Not all byte sequences are legal UTF-8, and you don’t want to have to figure out how to display them. If the kernel enforces these restrictions, ensuring that only UTF-8 filenames are allowed, then there’s no problem... all the filenames will be legal UTF-8. Markus Kuhn’s utf8_check C function can quickly determine if a sequence is valid UTF-8.

The filesystem should be requiring that filenames meet some standard, not because of some evil need to control people, but simply so that the names can always be displayed correctly at a later time. The lack of standards makes things harder for users, not easier. Yet the filesystem doesn’t force filenames to be UTF-8, so it can easily have garbage.

share|improve this answer
    
This seems to echo the explanation from out local admins, i will mark this as the answer going by the admins explanation. See my final edit –  mike-m Jul 31 at 16:24

One way to delete files/direcories like this is by their inode-reference.

To find the inodes for elements in current dir:

ls -i
14813568 mikeaâcnt

To delete this:

find . -inum 14813568 -delete
share|improve this answer
    
please see 5th edit. –  mike-m Jul 30 at 9:54
1  
No, this does not delete files by their inode. This looks for a file name for the given inode, and then deletes the file by its name. It cannot help here, as an attempt was already made with the correct name (alongside other attempts with an incorrect name). –  Gilles Jul 30 at 23:18
    
@Gilles - technically, it looks for an inode dentry and returns a filename, but I agree. –  mikeserv Jul 30 at 23:33
    
Maybe something like: mv 'file' $(echo 'file' | sed -e 's/[^A-Za-z0-9._-]/_/g') I've stolen this from server fault but I'm on handy and could not get the url –  vfbsilva Jul 31 at 3:56

You should not use non-ASCII characters in the command line since as you could see, for some reason, they won't necessarily correspond to the filename (Unicode has various ways for expressing accented letters). Something like:

rm -rf mike*

should work since the filename is directly generated by the shell. But make sure there's only one match (do an echo mike* first to confirm).

Well, if cd works, then there's no reason why rm or ls should say No such file or directory, so that the problem may be at the file system level.

Note: Do not use ls to find whether a directory is empty, but ls -a.

The directory may still be used by another process (including if it's the cwd of some process). IMHO, that's why it still "exists" but can yield errors, e.g. with ls; lsof may give you some information, but with NFS, you need to find which machine uses it. Especially with NFS, this can yield strange errors. ls -a in the parent directory could show you .nfs* files/directories in some cases.

When you get:

$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

I suspect that the file still exists in the directory table due to NFS caching and/or because it is used by another process, but without associated information. When ls tries to get information on the file itself, it gets an error as the file itself no longer exists (it is only in the directory table), hence the displayed error. Then ls outputs the filename because it is in the directory table. The fact you have question marks in one case but not in the other case is due to a display bug of ls IMHO (unrelated to your problem).

share|improve this answer
    
i had tried a wildcard earlier, it did not work, and i failed to post that attempt in my question, i will update with the result –  mike-m Jul 30 at 9:25
    
See my third edit. IMHO this is due to NFS (probably not corruption, but bad caching) and possibly the fact that another process is using the directory. In some cases, one needs to reboot everything (the server and the clients). –  vinc17 Jul 30 at 9:41
    
Maybe this could explain things, but i cant be sure since i dont have the priviledges to take it down for tests. See the 5th edit. –  mike-m Jul 30 at 9:56
1  
@vinc17 Please do not use "EDIT" in your answer, because for new reader is doesn't make sense (there is already an edit history) –  Bernhard Jul 30 at 9:58
    
iv added some lsof output, not sure whether it can tell you anything tho, –  mike-m Jul 30 at 10:19

I have personally tested using find's -exec directive:

$ mkdir -p mikeaâcnt
$ ls
mikeaâcnt
$ find -maxdepth 1 -type d -empty -exec rm -rf {} +
$ ls
$ 

The folder was correctly created and correctly removed.

As pointed out by @Igeorget, there's an even simpler method if you have GNU find:

$ find -maxdepth 1 -type d -empty -delete

I also tested this command, and it functions correctly

share|improve this answer
    
And if you use GNU's find, there's a -delete option too. –  lgeorget Jul 30 at 9:22
    
Please see 3rd edit, –  mike-m Jul 30 at 9:35

After getting the correct hex code of file / folder name (using whatever method one sees fit, I may choose ls --show-control-chars | xxd), some special construct should be used to address such characters when running under bash:

rmdir $'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

Otherwise backslashes are treated as vanilla backslash.

share|improve this answer
    
Please take a look at my edit (8th edit) –  mike-m Jul 30 at 15:29
    
@mike-m Of course that doesn't exist, because ls includes newline in output data and the "cnt" is duplicated. Maybe you can try directly copy and paste the line in my answer and see if it's effective? –  Abel Cheung Jul 30 at 16:01
    
Nope, still this: ``` rl]$ rmdir $'mikea\xc3\xa2\xc2\x81\xc2\x84cnt' rmdir: failed to remove `mikeaâ\302\201\302\204cnt': No such file or directory``` –  mike-m Jul 30 at 16:07
    
In that case it is quite likely a combination of NFS problem and the locale preventing most system utilities to pass incorrect non-UTF8 bytes. And it looks like the inode removal has worsened the situation. For now, the only way I can think of is setting your system to a locale-free environment (use "C" locale for LC_* and LANG env variables), and mount NFS without any character set options –  Abel Cheung Jul 30 at 16:28

Have you tried using rm -rf ./mikeaâcnt or rm -rf "./mikeaâcnt" or an absolute path? Also instead of rm, try rmdir ./mikeaâcnt.

share|improve this answer
    
part of the problem is that the characters in mikeaâcnt seem not to be the filename, but what ls displays, see the 3rd edit –  mike-m Jul 30 at 16:35

Have you tried to get the inode of that file with stat:

stat mike*

That should give you the inode number (and other data), and then you could try to delete it.

share|improve this answer
    
iv added an edit with stat behavour, –  mike-m Jul 30 at 18:44

I had similar issues. Do you have Gnome, KDE or some kind of Xwindow DM?. If you do open your file broser and remove the file from there.

It should work.

I would like to see a solution from the command line, but in my case and after losing a lot of time trying to figure out how to remove it from the command line I found that it was as simple as removing any other file from nautilus or any other file explorer (truth is I have only tried with nautilus).

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.