About six weeks ago I sent a message to port-pmax explaining
how fsck trashed level 0 ffs filesystems -- for example,
Ultrix filesystems.  Briefly, the superblock field 
``fs_maxsymlinklen'' ends up being all 1's on Ultrix filesystems.
Unless this field is reset to zero, fsck mistakely concludes
that  Ultrix filesystems can store a symlink's path directly
in the inode. Fsck then ``fixes'' this problem. This is clearly wrong.
Only filesystems with 

Even worse, the same thing happens on filesystems that are
upgraded from level 0 to level 1 -- i.e.,. with the command
``fsck -c 1'''. 

The following patch is *one* way to fix this.  It may not be the most
correct way.  The comment is purely for pedagogic purposes, and the
``#ifdef DSG'' should obviously go.  Perhaps the change should go
elsewhere, for example inside the switch that does setup for cvtlevel
== 1.  I'd do it regardless. Otherise, anyone who accidentally uses
NetBSD's fsck on a partition containing a level 0 (4.2) ffs filesystem
_will_ corrupt that filesystem. If it has any symlinks, that is.

Now that peope are actually picking up the unofficial pmax binary
distribution and *using* it, I think this really needs fixing.


If it was up to me I'd also change the kernel to sanity-check this
field for other filesystem levels as well. (I haven't checked a
post-1.0 release to see if anything like the fix I suggested to cgd
has been added.)

*** setup.c.DIST	Thu Jun 30 03:31:27 1994
--- setup.c.dsg	Sat Sep 17 20:08:50 1994
***************
*** 181,186 ****
--- 181,197 ----
  		newinofmt = 0;
  	}
  	/*
+ 	 * XXX Apparently necessary for Ultrix filesystems with symlinks
+ 	 */
+ #ifdef DSG
+ 	if (sblock.fs_postblformat == FS_42POSTBLFMT &&
+ 		sblock.fs_maxsymlinklen == -1) {
+ 		pwarn("IMPOSSIBLE IN-INODE SYMINK MAXLEN= %d, set to zero\n",
+ 			sblock.fs_maxsymlinklen);
+ 		sblock.fs_maxsymlinklen = 0;
+ 	}
+ #endif
+ 	/*
  	 * Convert to new inode format.
  	 */
  	if (cvtlevel >= 2 && sblock.fs_inodefmt < FS_44INODEFMT) {