Date: Tue, 7 May 1996 05:20:55 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, rnordier@iafrica.com, hackers@freebsd.org Subject: Re: dosfsck anyone? Message-ID: <199605070320.FAA01429@eac.iafrica.com> In-Reply-To: <199605070203.LAA18048@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 7, 96 11:33:15 am
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605070320.FAA01429>