Date: Tue, 7 May 1996 04:23:11 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: terry@lambert.org (Terry Lambert) Cc: rnordier@iafrica.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: dosfsck anyone? Message-ID: <199605070223.EAA01170@eac.iafrica.com> In-Reply-To: <199605062327.QAA22168@phaeton.artisoft.com> from "Terry Lambert" at May 6, 96 04:27:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605070223.EAA01170>