Date:	Wed, 22 Oct 1997 10:56:22 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>, djgpp-workers AT delorie DOT com
Subject:	Re: Clean handling of directory entries (was: Detecting fat32 drives)
In-Reply-To:	<Pine.SUN.3.91.971021130034.3667B-100000@is>
Message-ID:	<Pine.SUN.3.91.971022105440.7037K-100000@is>
MIME-Version:	1.0

> [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?
> 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.]

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?

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.  (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.)

> 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?

- Raw text -