Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!ptsfa!hoptoad!academ!killer!jfh
From: jfh@killer.UUCP (John Haugh)
Newsgroups: comp.unix.questions
Subject: Re: A couple questions
Message-ID: <876@killer.UUCP>
Date: Wed, 13-May-87 14:20:38 EDT
Article-I.D.: killer.876
Posted: Wed May 13 14:20:38 1987
Date-Received: Tue, 19-May-87 06:33:50 EDT
References: <3164@jade.BERKELEY.EDU> <2382@ncoast.UUCP> <1752@dg_rtp.UUCP> <314@desoto.UUCP>
Organization: The Unix(tm) Connection, Dallas, Texas
Lines: 66
Summary: I said it right the first time ...

In article <314@desoto.UUCP>, shz@desoto.UUCP (S. Zirin) writes:
> In article <634@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes:
> >In article <5835@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
> >>In article <816@killer.UUCP> jfh@killer.UUCP (John Haugh) writes:
> >>>If you wanted to, you could even find out the name
> >>>of the file that was connected to the descriptor.  (It is _not_ easy :-( )
> >>
> >>I would think it's actually impossible.  The kernel doesn't remember
> >>the name of the path you used to open an inode, and some descriptors
> >>(e.g. pipes) have no associated names.
> >
> >actually, it is possible. you know the inode associated with the descriptor
> >start at "/" and just keep looking for that i# keeping track of where you are.
> >Like the man said, it ain't easy, but it CAN be done.
> >-- 
> 
I wanted to remove Doug's remarks at this point and would like to have
included Guy Harris's as he had a much better disagreement with me than
Doug did.  This next guy does not understand the meaning of the phrase

	It is _not_ easy :-(	<-- frown face ...

> Actually, it is even more difficult.
Like I said, 

				X     X
                                   |
                                  ___
                                 /   \

>	... I-numbers are only unique within
> a filesystem.  You would first have to determine which filesystem your FD 
> pointed to, and then start the search from the root of that filesystem.
A file is described by a device/i-number pair to be more exact.  Pipes have
the pipe device for their device number or so I recall, unless they are named
pipes - 
> 	... Even 
> then it may not be possible to find the name of the file that was opened.
Did I say I want THE name or just a name? I forget, and I don't want to scroll
up in the editor - So I say now what I meant.  A NAME.  Multiple links to
a file are equivalent in USG Unix - only BSD Unix has 'symbolic links'
(last time I checked).  These might be different, in which case, all bets
are off.
> Assuming the FD did reference a file (as opposed to an unnamed pipe or other 
> 'magic' device), the last remaining name could have been unlinked.
Then I guess the file doesn't have a name.  In which case noone could find
out the name.  Sorry.  :-(
>	... Which
> brings us to the last point: there may be multiple links to the file.  The 
> best you could hope for is to find the first name or all names, not 
> necessarily the correct name.
> 
I think I handled this one in the paragraph a ways back.  If all paths lead
to the same inode, why should I care which one I want.  And if I do, I can
go look for the rest of the names.  Once again, it ain't easy.
> Check out the [usually undocumented] '-inum' option of FIND(1).
You work for AT&T right?  Well what is the deal with the '-depth' option
of find(1)?
> 
> Seth
> desoto!shz

- John.

Disclaimer -
	No disclaimer.  Whatcha gonna do, sue me?