Getting the pathname from a FILE*.

[Juergen Wagner]

In article <1645 at osiris.UUCP> guest at osiris.UUCP (Guest account) writes:
>...
>*PLEASE*  - if you are going to do things like using internal elements of
>"standard" libraries, try to access them in a more or less "standard"
>way. Most stdio libraries I've seen have a macro (but could be func, I
>guess) called fileno(myfd) - which returns just the information you are
>referring to. This way, your code won't break if someone does something
>cute or clever to the stdio library and include files.

I am aware of the fact that there is fileno(f). The point is: there
is a way to find out the file descriptor associated with FILE *f.

>Does this work if the file system is NFSsed, or something like that ?

If you do it properly: yes. Otherwise: no! The problem with NFS file systems
is that you have to walk through something other than the local file system.
I have a small program which determines the file system a file resides on,
and in case of NFS just returnes the remote host's name and the remote file
system's name. This allows you to walk through the directories as before.

At the time I posted my article, I didn't think of files being deleted while
they are still open somewhere else... This shouldn't cause any problems because
your function determining the file name could then just say so. Sockets, pipes,
ptys, and other stuff like raw devices can be handled with fstat. The inode
type will give you the information needed.

As for files having multiple links, I can only ask the question "what do you
want the routine to do?" Do you want a list of all names the file can be
accessed under, or are you merely looking for some way to associate this 
FILE * structure with *SOME* file name on your UNIX system? Personally, I
would be happy with the latter solution. If you get your hands on one of the
file's names, you've got the file in your grip!

>It almost seems to me that this is a case which stdio is not designed to
>handle. So - I'd say add another level of indirection. Write a routine
>that acts like fopen() - and one that acts like fclose(), etc. Have it
>store the name someplace, using only the "standard" interface to stdio,
>and then write another routine, or macro, that allows you to get the
>information back. I can't imagine that would be hard, and I expect it
>will work a LOT faster than reading your file system.

That's not always possible, as I've explained above. You can only find out
the names of files *YOU* have opened yourself. You will never be able to 
find out what stdin/stdout/stderr are connected to...

>Then again, maybe I don't understand what you're trying to do.

I guess, understanding a tool is not a necessary precondition for being able
to use this tool. I can fairly well work with UNIX but don't claim to have
understood all the bits of it! The issue is to provide some function which
performs its task in a way opaque to the user. One reason to do so is that
what this function really does is operating-system dependent. And there we
are again at the same point where you flamed at me because I preferred to 
mention _file instead of fileno(f). Opaqueness is a very important means of
keeping things understandable. If somebody knew that a certain function would
work more efficient under some circumstances than under other, he/she would 
use that knowledge in his/her programs. However, you know as well as I do that
this may turn out to be much less efficient on other systems.

# include <disclaimers/strawberry.h>

-- 
Juergen "Gandalf" Wagner,		   gandalf at csli.stanford.edu
Center for the Study of Language and Information (CSLI), Stanford CA