From owner-freebsd-hackers Mon May 6 16:37:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA17831 for hackers-outgoing; Mon, 6 May 1996 16:37:08 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA17826 for ; Mon, 6 May 1996 16:37:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA22168; Mon, 6 May 1996 16:27:20 -0700 From: Terry Lambert Message-Id: <199605062327.QAA22168@phaeton.artisoft.com> Subject: Re: dosfsck anyone? To: rnordier@iafrica.com (Robert Nordier) Date: Mon, 6 May 1996 16:27:20 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG In-Reply-To: <199605062243.AAA00740@eac.iafrica.com> from "Robert Nordier" at May 7, 96 00:43:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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.