From:	Eric Backus <ericb AT lsid DOT hp DOT com>
Subject:	fstat() yet again
To:	djgpp AT sun DOT soe DOT clarkson DOT edu (djgpp)
Date:	Sun, 29 May 94 1:18:24 PDT
Mailer:	Elm [revision: 70.85]

J. Alan Eldridge (alane AT wozzle DOT linet DOT org) wrote:
> I was just looking to solve the immediate problem. I didn't read the
> post fully :( I think the only way to get back to a name from the fd
> is if the runtime keeps track; AFAIK, DOS doesn't know.

Keeping track is fine for files opened by the program, but you can't
do that for stdin, stdout, and stderr.  All you have for those is a
file handle.  Still, if we don't have a better solution, implementing
this may be worthwhile.  We'd have to change open() to keep a table of
pathnames associated with file descriptors, and provide a backdoor way
for fstat() to look in the table.


Eli Zaretskii wrote:
> > 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.

This is beyond my limited DOS capabilities.  The requirement for the
file to be open is pretty ugly, and I suspect this method would end up
being pretty slow.  However, this is the only suggestion I've seen so
far that appears to solve the problem.


>   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, ...

But again, without a pathname (like with stdin) you can't do this.
--
				Eric Backus
				ericb AT lsid DOT hp DOT com
				(206) 335-2495

- Raw text -