Take a good look at that. None of the files have the owner write
bit set, which would be the eigth bit I think. The device numbers
generally range from 32 to 116. It looks like ASCII text got into
your inodes.
Yup, it's very clear somehow a data file got written into the inode
table. I'm not sure how it happened --- whether it was a confused disk
controller written data to a random spot on disk after a crash, or
whether it's a kernel bug, or something else, that's not clear.
Why does e2fsck keep the '?' files? They seem completely
illegal, at least as far as /bin/ls can tell.
I need to know what the exact octal mode is of the '?' mode. E2fsck
does get rid of the files with illegal modes. Somehow e2fsck thinks the
file is OK, but ls is being very confused.
If e2fsck finds several severely corrupt inodes, I think it
should go into a suspicious mode that throws out anything
with extremely weird permissions. For example, I've never
seen ------x-w- on a real file. AFAIK, Linux only uses the
sticky bit on directories: any non-directory with that flag
is corrupt. Suid and sgid have no meaning for device special
files, so those are invalid too.
The trick is picking a hueristic which is paranoid enough not to
accidentally cause users to lose data. I want to err on the side of not
removing files instead of being too aggressive about deleting files,
since removing illegal files from /lost+found is less work than forcing
administrators to restore files from backups when they don't have to.
(And we all keep backups, right? Of *COURSE* we do..... :-)
- Ted