Date: Tue, 7 May 1996 07:01:19 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: hackers@freebsd.org Subject: Re: dosfsck anyone? Message-ID: <199605070501.HAA01634@eac.iafrica.com> In-Reply-To: <199605070151.LAA17929@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 7, 96 11:21:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 May 1996, Michael Smith wrote: . . . . . > > Another thought: scattering (say) 'cross-linked on 3' info all over > > the place may actually be beneficial _because_ it makes things > > harder for the user. Problems like this really need an info-gathering > > pass before the suggested changes are approved. If users have to > > postpone decisions because of insufficient specific info, at least > > they are being forced to look at the overall picture first (while > > taking notes 8). > > Hmm. I guess it's a difficult call to find a solution that's OK for > the 'average' user (It's all OK, I've fixed everything, you only lost > a few files, now go play solitaire), and a more 'advanced' user (this > twisty diagram is your FAT filesystem on drugs). I was looking at the Linux 'dosfsck' the other day. This takes the approach of giving the user a whole list of choices to resolve any problem. Eg: 1) Drop file 2) Rename file 3) Auto-rename 4) Keep it However, as far as I know, the preferred Linux method is to run 'scandisk' under 'dosemu', and I don't think 'dosfsck' has ever been revised past the May 93 'alpha 0.1' version. (Though I may be wrong: I don't use Linux.) Maybe a lesson in this is to complement 'scandisk' and (where appropriate) do something different. One particular problem with 'scandisk' is that it is quite difficult to use it purely for diagnosis, and it has a tendency to quit the moment you disagree with any of its suggestion. Personally, I'd much rather have a command line utility (even a sort of 'fslint') ... which is why I prefer 'chkdsk'. And 'chkdsk' does check pretty well, if you include crashing, hanging, and running out of memory, as diagnostics. 8) > > > I particularly like the concept of moving questionable directory > > clusters to either the root or to some form of '/lost+found'. The > > main stumbling block, though, is that clusters (other than the > > first directory cluster) will be missing '.' and '..' entries. > > Pad with a dummy cluster full of deleted entries. > > It's not unreasonable to expect to be able to score a few free clusters. > If there aren't enough of them, then 'dosfsck' should just give up and > give an experienced user enough information to be able to safely delete > something to make space. > > eg. > > Not enough space to scribble on, can't make repairs! > Either abort and make some space, or answer yes to the following question. > DISCARD ALL AMBIGUOUS FILE DATA [yn]? > Hmm. This is lessening my reservations, but I'm still not 100% convinced that using 'free' clusters is the way to go. (Which is also why I'd prefer a pre-slotted 'lost.fnd'.) I'm worried about cases where the FAT is badly corrupted ... which really is probably why we have all the cross-links, anyway. If you can't basically rely on (a portion of) the FAT, the whole distinction between what is _really_ linked-in as FS data, and what is unallocated, becomes, well: maybe technically correct, but not necessarily pragmatic. Considering the trouble taken in other ways to protect and recover data, a few 0000s getting into the FAT by mistake seems to be error that needs providing for. I know that 'fsck' itself uses free space. But 'fsck' has everything in such a neat, smug Can't happen Hardware failure only Maybe hierarchy, and this just doesn't apply in the DOS world ... where designing "a better disk defrag utility" seems like a neat learn C++ project. 8( -- Robert Nordier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605070501.HAA01634>