Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

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

I've never seen this before (20 years of *nix). I've been trying to save my hard drive (details upon request) and have been pretty successful except there are some file that look like this:

$ ls -al
$ ?????????? ?    ?       ?      ? blah.txt

This file isn't affected by rm, rm -f, shred, mv, chown, chmod, or any other command I can think of.


# whoami

# rm -f blah.txt
rm: cannot remove `blah.txt': permission denied

# ls -la blah.txt
?????????? ?    ?       ?      ? blah.txt

Basically the same for any commands on this file.

Any ideas?

share|improve this question
20 years of Unix and you haven't seen a corrupted file system and/or broken HD before? Lucky you. – Janne Pikkarainen Dec 13 '10 at 9:16
Ah, that's what I thought it might be. Yes, I guess I've been lucky that way. The HD isn't broken, btw. Works fine. – bev Dec 14 '10 at 6:57
That usually means that the file name is listed in the directory, but it could not access its inode. It might have a bad inode number in the directory or the inode on the disk may have been corrupted. – mark4o Dec 15 '10 at 0:19
up vote 1 down vote accepted

Can you show us the output of 'lsattr blah.txt'? That would tell us which special flags this file has set.

Can you also check in dmesg (the kernel debug messages log) for anything new (run dmesg twice, once prior your attempts to remove a file, once afterwards, and see if anything new appeared at the bottom of the log).

A sample filesystem corruption message can look like that:

[86777.332361] EXT4-fs (dm-0): error count: 436
[86777.332365] EXT4-fs (dm-0): initial error at 1290174395: ext4_mb_generate_buddy:726
[86777.332367] EXT4-fs (dm-0): last error at 1292151653: ext4_mb_generate_buddy:726
[86777.332419] EXT4-fs (dm-8): error count: 1406
[86777.332423] EXT4-fs (dm-8): initial error at 1290623933: ext4_mb_generate_buddy:726
[86777.332425] EXT4-fs (dm-8): last error at 1292168399: ext4_mb_generate_buddy:726

and it indicates that ~86777 seconds since boot (this part might not be shown on your system, it depends on a kernel setting) there were two errors pertaining to EXT4 filesystem on my test machine.

share|improve this answer
@qdot, thanks for the tip. I can't try it yet because something I tried removed the problem. I 'touched' the file (I had given up on recovering data) and now the file just looks like a regular file with no content. As I wander though my fs I'm sure that I'll see more of these (2 so far), at which point I'll try lsattr and post the result. – bev Dec 14 '10 at 7:03
@qdot - ok here's the output: lsattr: Operation not supported While reading flags on blah.txt. BUT, lsattr doesn't return any info for any file on my system. It says: lsattr: Inappropriate ioctl for device While reading flags on <every file>. So, either lsattr doesn't work on reiserfs or, my hard-drive is corrupted but seems to be working just fine. Hmmmmm. Looking at dmesg now. – bev Dec 14 '10 at 8:15
ReiserFS: warning: is_tree_node: node level 0 does not match to the expected one 1 ReiserFS: sda3: warning: vs-5150: search_by_key: invalid format found in block 869576. Fsck? ReiserFS: sda3: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [265071 265097 0x0 SD] ReiserFS: warning: is_tree_node: node level 0 does not match to the expected one 1 ReiserFS: sda3: warning: vs-5150: search_by_key: invalid format found in block 869576. Fsck? – bev Dec 14 '10 at 8:19
Yah. Looks like there's a problem with the inode structure. I'm going to run fsck again. – bev Dec 14 '10 at 8:21
Ran fsck --check which now tells me there's a whole lot of corruption goin' on and I need to run fsck --rebuild-tree. So, having backed up my partition a couple of days ago, I ran that. I'll get back to you on the result. – bev Dec 14 '10 at 10:40

Your filesystem is corrupted. An fsck would likely help.

edit: unless you are using ReiserFS in which case fsck might corrupt it further ...

share|improve this answer
That was the first thing I did. It returned no bad blocks. – bev Dec 14 '10 at 6:58
It can't be anything else. Reconsider that possibility. However, I just noticed you are using ReiserFS. Be aware that ReiserFS fsck might just destroy your file system. That's one of ReiserFS design flaws ... – jlliagre Dec 14 '10 at 8:52
One of reiserfs's design flaws is that running reiserfsck might destroy a filesystem? That's good to know (after, of course, I ran reiserfsck on my filesystem) I'll try to find documentation on that. Lucky I backed everything up 2 days ago. Oh - and you were correct. I re-ran fsck and it showed me lots of problems. – bev Dec 14 '10 at 10:44
From The tree rebuild process of ReiserFS's fsck has attracted much criticism: If the file system becomes so badly corrupted that its internal tree is unusable, performing a tree rebuild operation may further corrupt existing files or introduce new entries with unexpected contents – jlliagre Dec 14 '10 at 11:52
@jlligre - thanks for the link. Pretty scarey. I'm pondering my next move. I have the entire partition backed up. I'm have reason to believe that the physical hd is ok, the current situation is due to me messing with 2 external hd's after I had done the back up (although I don't see what I did that caused this). Would you suggest I shred the partition and format with ext3? thx for the advice. – bev Dec 14 '10 at 23:30

chattr +i file makes a file completly write protected, even by root. It's called immutable. To delete or modify, you first have to make it mutable again by chattr -i file.

share|improve this answer
thanks for the help, unfortunately, it didn't work. Here's what happened: $> chattr -i blah.txt $> chattr: Permission denied while trying to stat blah.txt – bev Dec 13 '10 at 8:10

You must log in to answer this question.

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