From owner-freebsd-hackers Mon May 6 18:07:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA21228 for hackers-outgoing; Mon, 6 May 1996 18:07:24 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA21223 for ; Mon, 6 May 1996 18:07:19 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA17620; Tue, 7 May 1996 10:39:20 +0930 From: Michael Smith Message-Id: <199605070109.KAA17620@genesis.atrad.adelaide.edu.au> Subject: Re: dosfsck anyone? To: terry@lambert.org (Terry Lambert) Date: Tue, 7 May 1996 10:39:20 +0930 (CST) 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 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 Terry Lambert stands accused of saying: > > 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. I don't think _not_ using it is an option. > 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?). In which case the user gets a message "The root directory is full, filesystem repairs cannot proceed" and they're SOL. > 2) "." and ".." are artifacts of the search interface, not > artifacts of directory structure contents in a FAT/VFAT/VFAT32 > file system. Dig out a sector editor and have a look before you try that one again. Here's a tip : 0036a00: 2e 20 20 20 20 20 20 20 20 20 20 10 00 00 00 00 . ..... 0036a10: 00 00 00 00 00 00 f3 7e 2b 1f 02 00 00 00 00 00 .......~+....... 0036a20: 2e 2e 20 20 20 20 20 20 20 20 20 10 00 00 00 00 .. ..... 0036a30: 00 00 00 00 00 00 f3 7e 2b 1f 00 00 00 00 00 00 .......~+....... 0036a40: 41 54 54 52 49 42 20 20 45 58 45 20 00 00 00 00 ATTRIB EXE .... 0036a50: 00 00 00 00 00 00 c0 32 bf 1c 14 00 c8 2b 00 00 .......2.....+.. 0036a60: 43 48 4b 44 53 4b 20 20 45 58 45 20 00 00 00 00 CHKDSK EXE .... 0036a70: 00 00 00 00 00 00 c0 32 bf 1c 16 00 d1 2f 00 00 .......2...../.. > > 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? No. By the potential operation of the 'dosfsck' program, as stated in the preceeding paragraph. > Terry Lambert -- ]] 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 [[