2

I cannot delete a file that is copy of a backup of a backup... I don't remember all the filesystem character set it has passed by.

Anyway, today here's the file:

nas# ls -al
ls: cannot access Sécurité: No such file or directory
total 32
drwx------ 4 sambacam sambacam 20480 Jun  5 01:38 .
drwxr-xr-x 3 sambacam sambacam 12288 Jun  5 01:38 ..
d????????? ? ?        ?            ?            ? S??curit??
nas# cd S*
cd: 13: can't cd to Sécurité
nas# rm "Sécurité"
rm: cannot remove `S\303\251curit\303\251': No such file or directory
nas# rm S*
rm: cannot remove `S\303\251curit\303\251': No such file or directory
nas#

I even tried to code in Python without success:

nas# python
Python 2.5.2 (r252:60911, Jan 24 2010, 20:48:41) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> d=os.listdir('.')
>>> d
['S\xc3\xa9curit\xc3\xa9']
>>> d[0]
'S\xc3\xa9curit\xc3\xa9'
>>> os.remove(d[0])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 2] No such file or directory: 'S\xc3\xa9curit\xc3\xa9'
>>>

Any idea?

I already ran fsck to check for inconsistencies.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
CamilleHuot
  • 105
  • 1
  • 1
  • 6

2 Answers2

5

I think you've got worse problems:

d????????? ? ?        ?            ?            ? S??curit??

This means that ls(1) was unable to find permissions, link count, owner, group, size, or mtime of your file. All it has is a filename.

This could happen if the directory structure points to a file, but the inode for that file has gone missing. I would hope a fsck would find it and clean up the directory entry, but if that hasn't happened, you might not be able to ever empty this directory on this filesystem. (You could move it wherever you wanted, even into the /lost+found, and not be bothered by it again...)

Perhaps the debugfs(8) tool would be useful in learning more?

sarnold
  • 102,305
  • 22
  • 181
  • 238
  • For the time being, I've chosen your wonderful solution to move the directory to lost+found. Do you know how I could use debugfs to see/fix the problem? – CamilleHuot Jun 05 '11 at 17:15
  • @Camille, I'm reluctant to suggest anything, just because it could make your fs corruption _much_ worse. Please have backups. :) That said, it looks like you could use the `cd` command to navigate to the right directory. What happens next is a bit of a gamble: if you use `rm`, it will try to de-allocate the inode after unlinking the directory entry. Seems dangerous. If you use `unlink`, it will simply unlink the directory entry and leave the inode alone. (This is probably the safer choice.) But again, I can't stress the importants of backup strongly enough. :) – sarnold Jun 06 '11 at 05:23
3

Have you tried with the inode number trick? Do:

ls -ilb

The first number in that list is the inode number. The -b switch makes ls not try to print non-printable chars. Once you have the inode number from the file, try:

find . -inum the_number_from_above -exec rm -i {} \;

(BTW: that's UTF-8 encoding.)

I'm not sure it will work though. The fact that ls isn't finding the file's metadata (timetamps and permission bits) looks like filesystem corruption.

Mat
  • 202,337
  • 40
  • 393
  • 406
  • I don't understand how this help. `nas# ls -ibl ls: cannot access S\303\251curit\303\251: No such file or directory total 0 36626459 d????????? ? ? ? ? ? S\303\251curit\303\251 nas# find . -inum 36626459 -exec rm -i {} \; find: './S\303\251curit\303\251': No such file or directory nas# ` – CamilleHuot Jun 05 '11 at 17:18
  • 1
    Well in this case it appears that it doesn't because your FS appears to be corrupt. It does help in some cases where you can't manage to get the filename accepted by anything with more conventional means. – Mat Jun 05 '11 at 17:21