From owner-freebsd-hackers Fri May 3 12:16:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA03821 for hackers-outgoing; Fri, 3 May 1996 12:16:02 -0700 (PDT) Received: from eac.iafrica.com (h196-7-192-134.iafrica.com [196.7.192.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA03788 for ; Fri, 3 May 1996 12:15:50 -0700 (PDT) Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id VAA00877 for hackers@freebsd.org; Fri, 3 May 1996 21:11:54 +0200 From: Robert Nordier Message-Id: <199605031911.VAA00877@eac.iafrica.com> Subject: dosfsck anyone? To: hackers@freebsd.org Date: Fri, 3 May 1996 21:11:53 +0200 (SAT) X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm currently in the process of finishing off a BSD implementation of 'dosfsck', an 'fsck'-style utility for checking and repairing DOS FAT (and later VFAT) filesystems. The technical difficulties involved are not considerable; however, the four existing utilities I've tested (two DOS; two Unix) all get a number of fairly elementary test cases wrong. A reliable 'dosfsck' seems like a worthwhile addition to *BSD, at least insofar as it provides the ability to detect DOS filesystem errors. However, when it comes to fixing errors, there are a number of possible approaches, from simple(-minded) to (over-)complex. Depending on the level of interest (and subsequent use), a simple utility might be perceived as inadequate, or a complex utility as insufficiently debugged/proven to be depended on to fix 'real' problems. So, if anyone is sufficiently interested in a BSD 'dosfsck' to jump in with some feedback on the issue below (or on any more general issue), I'd appreciate it. Sample Design Issue It is pretty easy to detect DOS filesystem errors, and pretty easy to fix many of them (in that there is generally insufficient info for various approaches to be equally attractive). However, there are a few types of errors where it really becomes a toss-up, which approach to adopt. And disappearing up the wrong branch of a decision tree is likely to cause far more problems than doing nothing would. An example of this danger is the case of cross-linked directories. (If the directories /junk and /keep are cross-linked, they immediately or eventually merge into a common chain of directory entries, because they share all but zero or more initial allocation units). The simple-minded (or possibly KISS) approach of MS 'scandisk' and at least one Unix utility is as follows: If /junk appears before /keep in the root directory, the common entries will be silently allocated to /junk; only /keep will be identified as cross-linked; and the user will be prompted to truncate /keep. (And the other way round, if /keep appears before /junk.) This strategy can never have more than a 50% chance of success, and seems somewhat arbitrary, but requires less elaborate logic and/or internal data structures. A more flexible approach might be as follows: Directory '/junk' cross-linked on cluster 4. Truncate [yn]? [other stuff may intervene] Directory '/keep' cross-linked on cluster 4. Truncate [yn]? Advantages are: (a) both directories are identified as problematic (b) the user may choose which directory gets the common stuff (c) the user may elect to remove the common entries completely (In the case of cross-links, there are really two issues. One is the structural problem; the other is the possibility of directory corruption the cross-link may already have caused, or may be a symptom of.) The main problem with the more elaborate approach is that it introduces a 'static' vs 'dynamic' perplexity. Removing common entries entirely may radically affect the structure being worked on. And presenting info in terms of either the actual disk image, or the updated in-memory representation, may be equally confusing, in different circumstances. A related issue is whether to discard, or continue to queue, Change X (approved by the user) when - with hindsight - Change Y renders Change X unnecessary, or even misguided. One compromise might be not to allow truncation of both directories, thus avoiding large-scale structural changes. In this case, 'dosfsck' provides the means for eliminating detectable structural anomalies, and leaves it up to the user to cope with possible, non-detectable corruption. So the common clusters must be allocated to either /junk or /keep, and can be (re)moved by hand if found to be incorrect. (Example 1) Directory '/junk' is cross-linked on cluster 4. Truncate [yn]? y . . . . . Warning: directory '/keep' was also cross-linked on cluster 4. (Example 2) Directory '/junk' is cross-linked on cluster 4. Truncate [yn]? n . . . . . Directory '/keep' is cross-linked on cluster 4. Truncate [yn]? A further possible approach is simply 'So what? Provide an arbitrary fix for the problem. In the real world, most users will either restore from backup, or fix the problem themselves, either by hand or with some other utility.' Comments? -- Robert Nordier