To: Eric Backus <ericb AT lsid DOT hp DOT com>
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Library problems 
Date: Sun, 29 May 94 10:16:27 +0300
From: eliz AT is DOT elta DOT co DOT il

> Ugh.  Can we get the disk block number in a documented way?
> --

Nope.  Getting this is a non-trivial exercise in undocumented DOS.  It
involves:
	1) Accessing the file table in the program's PSP at the entry
which corresponds to the file's handle.  The number stored there is an
index into the DOS System File Table (SFT).
	2) Getting the address of the SFT via the infamous DOS List-of-Lists
structure, and reading the entry at the above index.  One of the fields there
is a starting cluster of the file.

  I hope I had this right (it's quite a time since I've read it in the `Undocu-
mented DOS' book).  As you see, it's not easy, and it only works for OPEN files
(i.e. stat() should open the file, call fstat(), the close it).
  There is another way: you could read the directories in the pathname in
sequence, starting at root, until you arrive to the one where the file resides,
then look at the file's entry inside the directory table.   You must do this
through BIOS (i.e. read sectors, not files), because DOS won't let you read the
directory as if it were a file.  In other words, if you have a file called, say,
c:/foo/bar/hello.c, then you start by reading the sector which holds the root
directory (a known absolute sector number); then you search the root directory
for the entry called foo and retrieve its first cluster; then you read that
cluster and search it for bar; then you read bar and search for hello.c; now
you find the first cluster of hello.c.  This will work, and IS documented, but
I suspect that for deeply nested directories it would be painstakingly slow.

  Maybe one of you out there heard of somebody who actually DID one of these
two jorneys?  Or is there another way?

  Btw, the TRUENAME command and the associated INT 21h function 60h has NOTHING
to do with this problem, as somebody rightfully have recently said.  And for
those who took the `exercise' part of J. Alan Eldridge (alane AT wozzle DOT linet DOT org)
posting seriously: function 60h is UNSUPPORTED by GO32, so you must go the hard
way by allocating conventional memory, simulating an interrupt, then moving the
info to protected mode memory: not a trivial exercise at all!

	Eli Zaretskii