Date: Thu, 23 Oct 1997 09:06:09 +1100
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: Clean handling of directory entries (was: Detecting fat32 dr
In-reply-to: <Pine.SUN.3.91.971022105440.7037K-100000@is>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com
Message-id: <199710222003.JAA24720@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: <Pine DOT SUN DOT 3 DOT 91 DOT 971021130034 DOT 3667B-100000 AT is>
Comments: Authenticated sender is <billc AT blackmagic DOT tait DOT co DOT nz>
Precedence: bulk

On 22 Oct 97 at 10:56, Eli Zaretskii wrote:

> I'm not sure I understand what's the problem.  Is the disk driver
> responsible for reading sectors, i.e. is it a replacement for Int
> 13h BIOS code?  If so, why does it need to know about the FAT?

The driver (lfn) uses either interrupts 217305 or 25/26 depending on 
what's available (or required), so it's not a replacement for 
anything. It's sortof the third layer you mentioned below.  The 
problem is that doesn't know about directories; everything is a 
cluster or sector.

> 
> OTOH, the FAT is conceptually part of the DOS filesystem, so why
> would you need the filesystem code to be oblivious to it?
> 
> Anyway, you could always introduce a third layer between these two
> which is responsible for taking the starting cluster number and
> translating a file-related operation into a series of sector reads
> that it passes to the disk driver.

Hmm, good idea. Although I said my driver level sort of did this, the 
interface is beginning to look like spaghetti.

> (And for God's sake, make the
> starting cluster available by some system call, so `stat' and
> `fstat' won't need to work so hard to get them.)

Yes, a very good idea.  What do you recomend? I already have a 
function that obtains the file's directory entry (and sfn and lfn as 
a by-product). This problem is how should an application get at it 
(remember, this is in a dos tsr that hooks int 21). An extran 2171xx 
function? An api entry point (how to obtain? 2f or 2171xx?)?


> > I've got to cope 
> > with OpenDos as well so I can't assume anything about the spare 
> > fields in a directory entry?
> 
> Does OpenDOS use directory entries differently?  If so, how can they
> be compatible to DOS-formatted disks?

According to RBIL, OpenDos (aka DR-DOS etc) uses the spare fields for 
the file's password.
Bill
--
Leave others their otherness.