From owner-freebsd-hackers Mon May 6 19:26:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA01371 for hackers-outgoing; Mon, 6 May 1996 19:26:04 -0700 (PDT) Received: from eac.iafrica.com (h196-7-192-145.iafrica.com [196.7.192.145]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA01349 for ; Mon, 6 May 1996 19:25:57 -0700 (PDT) Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id EAA01170; Tue, 7 May 1996 04:23:12 +0200 From: Robert Nordier Message-Id: <199605070223.EAA01170@eac.iafrica.com> Subject: Re: dosfsck anyone? To: terry@lambert.org (Terry Lambert) Date: Tue, 7 May 1996 04:23:11 +0200 (SAT) Cc: rnordier@iafrica.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG In-Reply-To: <199605062327.QAA22168@phaeton.artisoft.com> from "Terry Lambert" at May 6, 96 04:27:20 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 6 May 1996, Terry Lambert wrote: > > > 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. > > And if the relevant directory slots are occupied, it's hard to know > > how to proceed ('fsck' itself just expects the user to rectify the > > situation by hand). > > 1) There is a limit on the number of entries in "/" on DOS FS's > that isn't enforced on subdirectories. > > a) If you don't use "lost+found", you risk exceeding > this limit. > b) If you do use "lost+found", but it does not > preexist, AND the limit has already been reached, > you will not be able to create it (LOST.FND?). Agreed. Still, for the average DOS fixed disk FS, '/' has 512 entries. Compare this with values of 100 and 256 frequently recommended for slotting 'lost+found', when this was the practice. Fortunately, though, the situation isn't really critical. If the user can't be tempted by SORRY. CAN'T CREATE '/LOST.FND' DIRECTORY (DELETE /WINDOWS?) (or Mike Smith's earlier suggestion :), the worst is just the inconvenience of having to 'fsck' in multiple passes. (And if they really have >256 dubious/orphan clusters, this'll probably be the least of their worries.) I really like the idea of '/LOST.FND', though. I guess there's no need to stick with the MS 'FILE0001.CHK'-in-root approach. Could even name the re-linked file with the starting cluster number, also. > > 2) "." and ".." are artifacts of the search interface, not > artifacts of directory structure contents in a FAT/VFAT/VFAT32 > file system. Agreed; and DOS can mostly manage very well without them. But they are 'semi-structural' in the sense that - a) they must occupy predefined locations b) they are illegal DOS identifiers, so they are not really pure directory 'contents' either c) 'scandisk' will actually zap anything occupying their slots It would certainly be possible and workable to just relink questionable directory clusters to something in '/LOST.FND', but to swap one set of problems for another (missing '.' and '..') 'scandisk'-identifiable set of problems may not be the optimal solution. > > > When VFAT support is added, there is the additional problem that > > a single long filename may be spread across about 14 directory > > entries. If a cluster boundary intervenes between the 15 entries > > relating to a given file, the long filename will be lost. > > > > So there is the chance of introducing definite structural anomalies > > in the act of rectifying only possible/probable directory corruption. > > How will these anomolies be introduced? By (in violation of usage > semantics) caching? > > Further, one can identify a "long name cluster crossing" (is this even > legal?) per the above and preempt the association decision on that basis. By "the chance of introducing ... anomalies" I really just meant that, whereas FAT implies a nice convenient discrete set of 32-byte directories entries, VFAT (assuming "cluster crossing" is legal) means 'dosfsck' can't go blindly chopping up and relinking (to 'LOST.FND') questionable clusters, if the chop in question is going to sever the LFN, or the LFN to 8.3-name connection. (However, I'm probably misinterpreting the question, as I can't tie in "caching" - however loosely - with any of this.) I agree one certainly can detect the problem, and a VFAT LFN may even indicate which way the link might best be resolved. But the LFN hint won't invariably be definitive. The essential problem was a cluster being claimed by multiple directories. Instead of inviting the user to arbitrate the rival claims, the suggested solution was, "Don't link to '/X'; don't link to '/Y'; link to '/LOST.FND/Z'". The presence of a-cluster-crossing-LFN- emanating-from-'/X' certainly establishes the '/X' claim to at least one directory entry in the cluster. But (given that the cluster _was_ cross-linked), establishing the '/X' claim doesn't invalidate the '/Y' claim to some other directory entries (should such exist) within the same cluster. "Cluster crossing" must be legal, I reckon. Given that the smallest cluster is a sector, this gives only 16 directory slots. Subtract 2 for '.' and '..', and you'd have to waste the balance of the cluster for a worst-case filename. I gather, from the initial control byte in the name field, that the LFN segments can even appear in any order. (Unless - like half the "purely ornamental" boot sector BPB values, for instance - this is just another MS red herring.) However, I suppose I should add that I don't even currently own a copy of Win95, so this bit is all guesswork, anyway. 8) -- Robert Nordier