Date: Tue, 07 May 1996 18:43:06 EST From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: Terry Lambert <terry@lambert.org> Cc: hackers@freefall.FreeBSD.org Subject: Re: dosfsck anyone? Message-ID: <199605072243.SAA21637@exalt.x.org> In-Reply-To: Your message of Tue, 07 May 1996 14:43:43 EST. <199605072143.OAA24408@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > ??? 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605072243.SAA21637>