Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.questions
Subject: Re: A couple questions
Message-ID: <6582@mimsy.UUCP>
Date: Thu, 7-May-87 01:51:14 EDT
Article-I.D.: mimsy.6582
Posted: Thu May  7 01:51:14 1987
Date-Received: Fri, 8-May-87 05:39:40 EDT
References: <3164@jade.BERKELEY.EDU> <2382@ncoast.UUCP> <1752@dg_rtp.UUCP> <634@boulder.Colorado.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 30

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

>In article <5835@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes:
>>I would think it's actually impossible.

In article <634@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU
(Charles Shub) writes:
>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.

`It' can be done:  What can be done?  The problem is ill-defined
in the first place.  `Find *the* name of the file.'  Who says there
is only one?

	% ln file ../other/file

`Find *a* name of the file.'  That can be done iff the file has at
least one name.

`Find the internal name of the file.'  Easy: this is just the <dev,
ino> pair.  One problem is that few people wish to deal with this
form of the name.

Incidentally, `find / -inum <n>' takes a *long* time on a big system.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris