Mail Archives: djgpp-workers/1997/10/22/16:06:39
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.
- Raw text -