From owner-freebsd-hackers Tue May 7 15:44:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA17972 for hackers-outgoing; Tue, 7 May 1996 15:44:12 -0700 (PDT) Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA17964 for ; Tue, 7 May 1996 15:44:10 -0700 (PDT) Received: from exalt.x.org by expo.x.org id AA17048; Tue, 7 May 96 18:43:20 -0400 Received: from localhost by exalt.x.org id SAA21637; Tue, 7 May 1996 18:43:09 -0400 Message-Id: <199605072243.SAA21637@exalt.x.org> To: Terry Lambert Cc: hackers@freefall.FreeBSD.org Subject: Re: dosfsck anyone? In-Reply-To: Your message of Tue, 07 May 1996 14:43:43 EST. <199605072143.OAA24408@phaeton.artisoft.com> Organization: X Consortium Date: Tue, 07 May 1996 18:43:06 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > ??? What does that mean, they're "artifacts of the search interface..." > > > > > > It's been years since I used MS-DOS enough to care about poking around > > > in the file system with Norton Utilities, but as I recall "." and ".." > > > are just like any other directory entry in a directory. > > > > . and .. are offical needed, it is used by MS-Dos to load quicker the actual > > directory (. points to the first cluster of the diretory) or to go one > > directory up again (.. points to the first cluster of the mother directory or > > to 0 for roo directory) > > Windows95 IFS uses absolute paths for all FS lookups. So does NT. > > *ALL* FS lookups. While running DOS/Windows. > > Same goes for DOS 7.0 shells running INT 21 emulation for programs > running in DOS "Command" on Win95. > > If you "cd .." you *don't* get a ".." at the IFSMgr_SetReqHook() > call level. You get an absolute path with the ".." parsed back. > Fine, but what does that have to do with how the bits are laid on on the disk in FAT/VFAT/VFAT32? My guess is that FreeBSD programs don't care too very much about INT21 emulation or IFSMgr_SetReqHook. :-) On the disk there are "." and ".." directory entries. If the Windows IFS chooses to parse out the ".." in a filespec, that doesn't sound like something that affects how dosfsck will work. -- Kaleb KEITHLEY