Mail Archives: djgpp-workers/1997/10/24/06:36:32
On Thu, 23 Oct 1997, Bill Currie wrote:
> 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.
It could maintain a table where for each drive you set a flag that
tells which function to call, based on a test which is done when that
drive is first accessed.
> > (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?)?
The Interrupt List already documents a function for getting the
starting cluster of a file (21440Dh/CX=0871h), so you might just
support it. Note that 214411 should know about it and report that
this service is supported.
Btw, does DOS 7.1/Windows 95.1111 support this call? I couldn't get
it to succeed on every version of DOS I tried through 7.0, and neither
on Windows 95.950. The latest version of `stat' already calls this
function if it is supported (you can get the source at Tom Demmer's
libc patch site, or from me), but I have yet to see it work. It would
be interesting to see how e.g. `ls' from Fileutils reports true inode
numbers when you say "ls -i", if your OS supports that call.
As for directory entry, you could use the reserved fields of
`findfirst' call. I think there's enough space there.
- Raw text -