Sys V inode bug

[Brian D. Botton]

In article <213 at unf7.UUCP> tfb at unf7.UUCP (t blakely) writes:
>. . . .  Is fsck buggy or am I causing the problem with . . . . . . .
          ^^^^^^^^^^^^^

  I lead a team of people that manages a network of 4 VAXen, an Alliant,
and ~300 Suns with 3 of the VAXen running Sys V.2.0.2, and I must state
that I don't trust the Sys V fsck.  More than once I've run fsck after a
crash and had it claim that the file systems are okay.  Then I'll cd into
a directory, do an ls, and get the following (or at least close to this):

	ls: . not found

  That's right, a directory without . and .. :-(.  Now maybe I'm expecting
too much, but I really think fsck should be able to do better than this.
To be honest, I haven't had the time to dig into why fsck is so brain
damaged.  Thoses VAXen have been around a long time and some are going away.
The rest are getting upgraded to V.3.1.1 and Mt. Xinu 4.3 (we are running
a beta 4.2 BSD now, current aren't we, :-).

>. . . . . . .  I've only been working with SysV for about a
>year now, but in several years on Berkeley systems I've never had any
						    ^^^^^^^^^^^^^^^^^^
>problems like this. . . . . . .
 ^^^^^^^^^^^^^^

  Neither have I, in fact, I trust the Berkeley fsck as much as I distrust
the Sys V fsck.

>. . . . . . . . . .If so, what's wrong
				  ^^^^^
>with AT&T (aside from the obvious) that they can't fix something
 ^^^^^^^^^
>like this?

  Careful, the phone police may show up at your door, ;-).

  I know that this hasn't helped your problem, but I thought you'de like
to know that you're not alone with fsck problems.

-- 
     ...     ___
   _][_n_n___i_i ________		Brian D. Botton
  (____________I I______I		laidbak!botton
  /ooOOOO OOOOoo  oo oooo