Date: Mon, 6 May 1996 18:20:01 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: rnordier@iafrica.com (Robert Nordier) Cc: hackers@freebsd.org Subject: Re: dosfsck anyone? Message-ID: <199605060850.SAA14400@genesis.atrad.adelaide.edu.au> In-Reply-To: <199605031911.VAA00877@eac.iafrica.com> from "Robert Nordier" at May 3, 96 09:11:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Nordier stands accused of saying: > > 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. Yay! > A reliable 'dosfsck' seems like a worthwhile addition to *BSD, at > least insofar as it provides the ability to detect DOS filesystem > errors. Agreed. > 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). *snort* 8) > 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). Hmm. I'd be inclined to suggest that all the directory entries out of the merged section should be moved into the equivalent of a 'lost+found' directory, perhaps in a subdirectory containing a .REPORT file indicating where they came from and when... Putting them in one or another of the original directories hides the problem. I don't think that the aim of a filesystem repair tool under such circumstances should be to try to hide the problem, but rather to facilitate the manual repair of the filesystem. > 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]? Directories '/junk' and '/keep' crosslinked on cluster 4. Move files to '/losfound.fsk/dosfsck.001' ** ANSWERING NO WILL DISCARD FILES ** [yn]? > 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. I think that it would be desirable, where possible, to present the symptoms of a single problem together. I'm aware this leads to messages like : Too many directories (>256) crosslinked. Suggest discarding filesystem! > 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. Is it difficult (and thus messy) to take the common clusters and allocate them to a third directory (as in the example above)? If so, there's a precedent for taking the easier way out 8) > 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.' Good point. Hence, perhaps, the idea that data in contention should be kept but removed from any potentially incorrect location, keeping only those parts of the tree that appear to belong where they are. (I'm aware that this is somewhat of a subjective decision 8) > Robert Nordier -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605060850.SAA14400>