Date: Thu, 23 Oct 1997 09:06:09 +1100 From: Bill Currie Subject: Re: Clean handling of directory entries (was: Detecting fat32 dr In-reply-to: To: Eli Zaretskii 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: Comments: Authenticated sender is 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.