From owner-freebsd-hackers  Mon May  6 20:23:35 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id UAA04913
          for hackers-outgoing; Mon, 6 May 1996 20:23:35 -0700 (PDT)
Received: from eac.iafrica.com (slipper119245.iafrica.com [196.7.119.245])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA04906
          for <hackers@freebsd.org>; Mon, 6 May 1996 20:23:23 -0700 (PDT)
Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id FAA01429; Tue, 7 May 1996 05:20:56 +0200
From: Robert Nordier <rnordier@iafrica.com>
Message-Id: <199605070320.FAA01429@eac.iafrica.com>
Subject: Re: dosfsck anyone?
To: msmith@atrad.adelaide.edu.au (Michael Smith)
Date: Tue, 7 May 1996 05:20:55 +0200 (SAT)
Cc: terry@lambert.org, rnordier@iafrica.com, hackers@freebsd.org
In-Reply-To: <199605070203.LAA18048@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 7, 96 11:33:15 am
X-Mailer: ELM [version 2.4 PL24 ME8a]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, 7 May 1996, Michael Smith wrote:
> 
> Terry Lambert stands accused of saying:
. . . . .
>                 The only useful think about '..' is that it points to the
> starting cluster of the parent directory.
> 
> > What about ".." in "/"?
> 
> There isn't one 8)
> 

The '.' and '..' are really more decorative than useful as far as MS-DOS
is concerned.  I've got some notes by Mike Podanoffsky (who wrote a DOS
clone) that begin:

   A simple proof can be created to demonstrate that MSDOS (and RxDOS)
   do not use or need the . and .. entries in a directory.

> > > > How will these anomolies be introduced?  By (in violation of usage
> > > > semantics) caching?
> > > 
> > > No.  By the potential operation of the 'dosfsck' program, as stated in
> > > the preceeding paragraph.
> > 
> > How does a cross-link get created is what I was asking...?
> 
> Ah.  I don't think we're expecting any to be created by the new DOSFS, but

8)

> you'll get them under DOS if 'smartdrive' loses its marbles, or if a 
> program with a rogue pointer scribbles on DOS' buffers, or if some twonk
> hits RESET while the FAT is being updated, or if DOS/Win/whatever 
> takes a dive while the FAT is in an inconsistent state.
> 
> None of the MS FAT filesystem drivers seem to place much emphasis on
> maintaining filesystem consistency.

One very weak link in the whole business is the way MS-DOS patiently
maintains a backup copy of the FAT, but never uses it except if a
primary FAT sector develops a media error.  And 'scandisk', if FAT
inconsistencies are present, doesn't (as I recall) even offer a choice
of FATs, but always uses the primary one.

For some reason, when things go wrong, DOS tends to prefer to write
stuff over the boot sector or primary FAT, probably as some internal
int 13h equivalent of a NULL pointer dereference.

FAT data is relatively unusual in that, discounting 0 (free cluster)
and 0xfff8-0xffff (end of cluster chain), all other evenly-aligned words
(for FAT-16) should have unique values.  Because data obtained from any
random location is much more likely to be less evenly-distributed over
0x2..0xfff6, the result will almost inevitably be cross-linked clusters.

I guess it should be possible to tell, by looking at the cluster numbers
involved, whether your FAT got trashed by text or binary data. 8)

-- 
Robert Nordier