Date: Tue, 21 Oct 1997 08:59:36 +1100
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: Detecting fat32 drives.
In-reply-to: <Pine.SUN.3.91.971020145914.29791J-100000@is>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com,
        ralf AT pobox DOT com
Message-id: <199710201956.IAA12476@teleng1.tait.co.nz gatekeeper.tait.co.nz>
Organization: Tait Electronics Limited
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <199710192150 DOT KAA06994 AT teleng1 DOT tait DOT co DOT nz gatekeeper.tait.co.nz>
Comments: Authenticated sender is <billc AT blackmagic DOT tait DOT co DOT nz>
Precedence: bulk

On 20 Oct 97 at 15:00, Eli Zaretskii wrote:

> We need to think about this in the context of libc functions. 
> Suppose some function needs to know whether to issue a
> FAT32-specific call or not.  If it will try to call 217305 every
> time, won't that make that function prohibitively slow?  If it will,
> we need a faster way.

I was thinking of a once off call that sets a flag indicating the 
need for FAT32 calls (that's what I did in my lfn driver, but 
reversed)

> What happens if you issue a FAT32 call on a FAT16 drive but under a
> version of DOS/Windows that supports FAT32?  Will that work or fail?

I don't know about FILE calls, but I know that the sector calls work 
because debug can still read/write floppy drives and I know (from 
disassembling debug) that only 217305 is used for sector access.

I'll try out the FAT32 file calls on a floppy, but I honestly can't 
imagine them not working on non fat32 drives if they work at all (ie 
the calls are either legal or they're not, no dependency on the 
drive, just the OS).



I can't prove it, but I wouldn't be supprised if the FAT32 version of 
W95 doesn't actually know anything about FAT12 or FAT16 at the 
filesystem level (except for directory entries).  I found it much 
easier to treat all drives as FAT32 and just use 32 bit cluster 
numbers, letting the disk driver worry about the details

[complete sideline, how do I get my filesystem level that's not 
supposed to know about fat types (ideally cluster numbers are just 
magic cookies) handle directory entries cleanly? I've got to cope 
with OpenDos as well so I can't assume anything about the spare 
fields in a directory entry? Also, my disk driver level knows about 
the three fat types but knows nothing about directory entries, so it 
can't be used to extract the starting cluster either.  Could someone 
suggest a clean solution? At the moment the filesystem level peeks at 
the fat type in the disk level in a couple of places.]
Bill
--
Leave others their otherness.