Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Mar 1997 16:24:04 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        joerg_wunsch@uriah.heep.sax.de
Cc:        hackers@freebsd.org, port-i386@netbsd.org, darrenr@cyber.com.au
Subject:   Re: dump for MS-DOS partitions.
Message-ID:  <199703242324.QAA23896@phaeton.artisoft.com>
In-Reply-To: <19970324214916.YH08116@uriah.heep.sax.de> from "J Wunsch" at Mar 24, 97 09:49:16 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> Also, we do already have a mkdosfs(8), maybe somebody would even write
> a dosfsck(8).  (mkdosfs doesn't understand harddisks however.  I'm not
> the right person to ask for this, my DOS knowledge is too weak.)

A fsck is relatively trivial.

That's because there is no difference between a directory entry and
a physical inode in the MSDOSFS... many of the checks performed by
the FFS fsck are simply not applicable to the idea of checking an
MSDOSFS.

The biggest concerns of chkdsk are:

o	Clusters referenced by more than one file

o	Clusters that appear to be refernced, but aren't

In the first case, the cluster chais are typically duplicated and
unreferenced by the second file, makeing one of the files "whole"
and the other "corrupt" (by definition, the situation can not arise
in normal operation).

In the second case, it asks "convert cluster chains to files?", and
makes files to contain the chains.  This, also, can never happen
during normal operation.


As far as directory entries are concerned: the unity of a directory
entry and an inode means that you can never have an unrefernced inode,
and you can never have an entry that references a bad inode.

Again, this can never occur in normal operation.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703242324.QAA23896>