From owner-freebsd-hackers Mon Mar 24 15:37:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19744 for hackers-outgoing; Mon, 24 Mar 1997 15:37:05 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA19735 for ; Mon, 24 Mar 1997 15:37:01 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA23896; Mon, 24 Mar 1997 16:24:04 -0700 From: Terry Lambert Message-Id: <199703242324.QAA23896@phaeton.artisoft.com> Subject: Re: dump for MS-DOS partitions. To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 24 Mar 1997 16:24:04 -0700 (MST) Cc: hackers@freebsd.org, port-i386@netbsd.org, darrenr@cyber.com.au In-Reply-To: <19970324214916.YH08116@uriah.heep.sax.de> from "J Wunsch" at Mar 24, 97 09:49:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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.