I tried to get a clean output. Here's the best and latest I saved:
EXT2-fs error (device 03:43): ext2_find_entry: bad entry in directory #215118: inode out of bounds - offset=8048, inode=9920364, rec_len=20, name_len=12
I decided I better reboot for clean shutdown so it would go through
fsck from scratch. Tried to quit out of gnus in xemacs, and had
*lots* of troubles with saving .newsrc.eld.
So I did reboot for clean shutdown so it would go through fsck from
scratch, which it did automatically thankfully (the filesystem had
errors). I didn't see it obviously actually fix anything.
When I came back into xemacs, .newsrc.eld had lots of errors in it
according to gnus.
It's strange, none of .newsrc* have inodes near the size of that
number 9920364:
Q:~$ ls -lid .newsrc*
215058 -rw-r--r-- 1 ulmo users 3245 Jun 19 17:19 .newsrc
215368 -rw-r--r-- 1 ulmo users 201 Mar 29 17:29 .newsrc-NEWS.Panix.Com
216069 -rw-r--r-- 1 ulmo users 624 Jun 2 14:43 .newsrc-NNTP.Q.Net
216089 -rw-r--r-- 1 ulmo users 104 Mar 19 20:08 .newsrc-dribble~
215935 -rw------- 1 ulmo users 185 Nov 15 1995 .newsrc-news.zone.net
215320 -rw-r--r-- 1 ulmo users 2306 Mar 31 03:43 .newsrc.......... 188614 drwxr-xr-x 2 ulmo users 1024 Feb 23 17:46 .newsrc.backup/
215572 -rw-r--r-- 1 ulmo users 172437 Oct 5 1995 .newsrc.bak
215059 -rw-r--r-- 1 ulmo users 74201 Jun 18 18:10 .newsrc.eld
215064 -rw-r--r-- 1 ulmo users 73928 Jun 17 16:30 .newsrc.eld~
215057 -rw-r--r-- 1 ulmo users 2949 Jun 17 16:30 .newsrc~
Q:~$
But looking at the "in directory" part (look again for reference ...)
EXT2-fs error (device 03:43): ext2_find_entry: bad entry in directory #215118: inode out of bounds - offset=8048, inode=9920364, rec_len=20, name_len=12
... I see that this makes sense at least ...
Q:~$ ls -ldi .
215118 drwxr-xr-x 728 ulmo users 27648 Jun 19 17:38 ./
Q:~$
The "in directory #215118" is referring to inode #215118. Good.
Oh, I see -- inode is out of bounds. (Bear with me when I'm getting
over this cold -- I think slowly.)
ahh.
Well, I agree :)
So something about xemacs doing its segmentation fault after trying to
restore from a 15 minute suspension (while in gnus mode) and crashing
led to this odd ext2 bug happening.
I don't care how buggy xemacs is, I don't think ext2 ought to do this
to its directory structure or inodes. If I can be of any further help
diagnosing this one, please do suggest how.
Thanks very much,
Bradley Allen <Ulmo@Q.Net>
P.S. Nothing is in lost+found.
P.P.S. I can easily get xemacs to crash after suspending it.