Date: Fri, 3 May 1996 21:11:53 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: hackers@freebsd.org Subject: dosfsck anyone? Message-ID: <199605031911.VAA00877@eac.iafrica.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605031911.VAA00877>