Date: Tue, 7 May 1996 11:21:19 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: rnordier@iafrica.com (Robert Nordier) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: dosfsck anyone? Message-ID: <199605070151.LAA17929@genesis.atrad.adelaide.edu.au> In-Reply-To: <199605062243.AAA00740@eac.iafrica.com> from "Robert Nordier" at May 7, 96 00:43:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Nordier stands accused of saying: > > > > Too many directories (>256) crosslinked. Suggest discarding filesystem! > > That's a great line. There's got to be a place for it, even if the > error condition has to be specially arranged. 8) There isn't enough humour in software these days 8( > One consideration is that problem-by-problem info may be difficult > to present intelligibly, if the filesystem structure has become really > confused. > > Consider the case of five directories (/a /a/b /a/b/c /d /e) which > have become cross-linked: > > +-<----------------------------+ > +-----2 | +-----3 +-----4 | > <a> ---> | | -+-> | | -+-> | <b> | | > +-----+ +-----+ | +--+--+ | > <d> ------------------------->-+ | +--+--5 > +--+--> | <c> | > | +-----+ > <e> ----------------------------------->-+ I would be inclined to summarise this as : The following directories are snarled : /a ???/c /e ???/b /d Files which cannot be accurately associated with a directory will be placed in /lost.fnd/00000001.fsk/ And then leave cluster 2 on /a, and throw everything else in the lost.fnd directory. (ie. clusters 3,4 and 5) > 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 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]? > If there was a good solution to the '.' and '..' problem, this > would be distinctly attractive. One way out, I suppose, would be > to use unallocated clusters, if necessary, and actually transfer > the questionable directory entries individually (and somewhat > intelligently, for VFAT), making the process a partial directory > rewrite rather than a relink. That's actually not a bad idea. It wouldn't be unreasonable to keep a small pool of spare clusters hung off the lost.fnd directory, and use these perhaps. However all this presumes that the FAT filesystem is under the general care of 'dosfsck', which is unlikely to be the case. I think that 'dosfsck's basic aim should be to render the filesystem consistent, and leave any 'fancy' reconstruction to either the user or a DOS tool written by someone who gets paid to suffer 8) > within a directory, for instance). I'll give the stuff a break > for a bit, and then consider the suggestions again.... Good idea 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?199605070151.LAA17929>