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?

  • 10
    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

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.

  • @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 ...

  • 1
    That was the first thing I did. It returned no bad blocks. – bev Dec 14 '10 at 6:58
  • 1
    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
  • 1
    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
  • 1
    From en.wikipedia.org/wiki/ReiserFS: 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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.