Date: Mon, 6 May 1996 16:27:20 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rnordier@iafrica.com (Robert Nordier) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: dosfsck anyone? Message-ID: <199605062327.QAA22168@phaeton.artisoft.com> 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
> 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?).
2) "." and ".." are artifacts of the search interface, not
artifacts of directory structure contents in a FAT/VFAT/VFAT32
file system.
> 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.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605062327.QAA22168>