fsck creates disk errors

[Skye Stollmeyer]

In article <269 at hawkmoon.MN.ORG> det at hawkmoon.MN.ORG (Derek E. Terveer) writes:
>In article <6808 at well.UUCP>, dave at well.UUCP (Dave Hughes) writes:
>> [First problem]
>> Secondly - if modem-callers  who do NOT have terminal emulation
>> programs run it - plain tty mode - the whole session is 
>> punctuated by OOPS's (coming from curses, I guess), and is
>> totally unsatisfactory.
>
>I've run into the exact same problem that you have seen when entering new
>terminals into the /etc/termcap file.
>
>Apparently, the OOPS is an exclaimation of suprise by curses when it encounters
>things in the termcap file it doesn't understand.  This doesn't seem to be a
>documented feature.  I have *not* seen this problem in terminfo files.
>
>I have seen the OOPS result in two different cases:
>
>	1. Any kind of capatilized capabilities in the termcap entry, such as
>	   "AL", etc.  Just delete all capatilized capabilities.  These are
>	   mostly "multiple commands" anyway, such as >1 line delete, etc.,
>	   which vi doesn't seem to use anyway!  (arg! (:-()
>
>	2. Any time there are the following type of push strings in the
>	   capability, for example, %p1 or %p2.  I simply deleted these strings
>	   with "1,$s/%p[12]//g" in vi.  The removal of these substrings from
>	   the capabilities removed the obnoxious OOPS from the screen and
>	   didn't seem to affect the curses capability.
>
>Good luck, hope this helps!
>
>derek


I've run fsck a number of times in straight succession and it continues
to find the same bad inode count in superblock, another bunch of blocks
to salvage from who knows where, even though i always answer yes to all the
questions. The number of blocks in the system is always slightly different
though. Is fsck known to be broken in this way? I've heard it is known
to happen after recompiling vpix or other device drivers into the kernel.