|
Home > Archive > Unix Programming > May 2005 > getting pathname from descriptor
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
getting pathname from descriptor
|
|
| tom dailey 2005-05-27, 8:48 pm |
| Is there a way to get the pathname associated with an open file
descriptor?
Thanks,
Tom Dailey
| |
| Jens.Toerring@physik.fu-berlin.de 2005-05-27, 8:48 pm |
| tom dailey <tom.dailey@verizon.net> wrote:
> Is there a way to get the pathname associated with an open file
> descriptor?
No.
A) The file you have an descriptor for may already have been unlinked.
B) There might be several different paths to that file, resulting in
lots of different names (hard/soft links).
C) A file descriptor is not necessarily associated with a file at
all, it could e.g. be a pipe, a socket etc.
Ping-pong question: What do you need that information for? Perhaps
there are other ways you can do what you want to do...
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de
| |
| SM Ryan 2005-05-28, 2:48 am |
| tom dailey <tom.dailey@verizon.net> wrote:
# Is there a way to get the pathname associated with an open file
# descriptor?
Sort of if the file is still linked to a directory. Do an fstat to get the
device and inode numbers, then recursively descend from the mount point of
that device and do a lstat looking for a matching inode number. There may be
more than one name for the file.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
If your job was as meaningless as theirs, wouldn't you go crazy too?
| |
| Kurtis D. Rader 2005-05-28, 2:48 am |
| On Sat, 28 May 2005 00:45:46 +0000, Jens.Toerring wrote:
[vbcol=seagreen]
> tom dailey <tom.dailey@verizon.net> wrote:
To add to Mr. Toerring's response, which is correct for the general case,
this can be done for a subset of the general case. But not portably. And
with all the issues noted by Mr. Toerring. For example, if you're running
on Linux see /proc/$pid/fd/. But, obviously, this isn't portable, does
not guarantee the path is still valid, does not guarantee there aren't
other paths to the same file, and there may not even be a path associated
with the file descriptor (e.g., it's a network socket).
| |
| Måns Rullgård 2005-05-28, 7:48 am |
| "Kurtis D. Rader" <krader@skepticism.us> writes:
> On Sat, 28 May 2005 00:45:46 +0000, Jens.Toerring wrote:
>
>
> To add to Mr. Toerring's response, which is correct for the general case,
> this can be done for a subset of the general case. But not portably. And
> with all the issues noted by Mr. Toerring. For example, if you're running
> on Linux see /proc/$pid/fd/. But, obviously, this isn't portable, does
/proc/self/fd is a convenient shortcut.
> not guarantee the path is still valid, does not guarantee there aren't
> other paths to the same file, and there may not even be a path associated
> with the file descriptor (e.g., it's a network socket).
The links in /proc/pid/fd will indicate if a file descriptor is a pipe
or a socket.
--
Måns Rullgård
mru@inprovide.com
| |
| tom dailey 2005-05-29, 2:48 am |
| Jens.Toerring@physik.fu-berlin.de wrote:
> tom dailey <tom.dailey@verizon.net> wrote:
>
>
>
> No.
>
> A) The file you have an descriptor for may already have been unlinked.
> B) There might be several different paths to that file, resulting in
> lots of different names (hard/soft links).
> C) A file descriptor is not necessarily associated with a file at
> all, it could e.g. be a pipe, a socket etc.
>
> Ping-pong question: What do you need that information for? Perhaps
> there are other ways you can do what you want to do...
>
> Regards, Jens
The reason is not profound, and there are other ways to do what I want
to do. I imagine we've all had the experience of writing a function that
performs some activity using a file descriptor (FD) passed as a
parameter, and then needing to report an error associated with the FD.
In such a case, it would be best to tell the user the pathname
associated with the error -- the FD generally tells him nothing useful.
One can, of course, define a structure like
typedef struct
{
char* pathname_p;
int fd;
...and maybe other stuff, too
}
open_file_control_t;
and pass around pointers to objects of this type instead of FDs. It
would just be nice if there were a POSIX way to get the pathname from
the FD, without all this rigamarole.
Tom
| |
| Rich Teer 2005-05-29, 2:48 am |
| On Sun, 29 May 2005, tom dailey wrote:
> to do. I imagine we've all had the experience of writing a function that
> performs some activity using a file descriptor (FD) passed as a
> parameter, and then needing to report an error associated with the FD.
Agreed. The usual way is for the function to return an error (setting
errno as required. The calling function (which presumably knows the
file's name) then prints a meaningful error message, complete with the
file's name. (Return errors up the calling stack as require.)
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| Kamal R. Prasad 2005-05-30, 2:48 am |
| I believe the OS ought to store the pathname which was passed to
open() to get the fd (if it cannot provide the user with access to the
namecache).
regards
-kamal
| |
|
|
| William Ahern 2005-05-30, 7:53 am |
| Kamal R. Prasad <kamalp@acm.org> wrote:
> I believe the OS ought to store the pathname which was passed to
> open() to get the fd (if it cannot provide the user with access to the
> namecache).
That would really only make sense where all descriptors were addressable via
the filesystem. In Plan9 everything is representated as an object in the
filesystem, so not suprisingly they have a standard system call--fd2path().
On Unix often times the majority of descriptors in a process are for pipes
or sockets, neither of which have a "path" in the Unix sense.
| |
| Russell Shaw 2005-05-30, 7:53 am |
| William Ahern wrote:
> Kamal R. Prasad <kamalp@acm.org> wrote:
>
>
> That would really only make sense where all descriptors were addressable via
> the filesystem. In Plan9 everything is representated as an object in the
> filesystem, so not suprisingly they have a standard system call--fd2path().
>
> On Unix often times the majority of descriptors in a process are for pipes
> or sockets, neither of which have a "path" in the Unix sense.
I started a thread exactly like this a few weeks ago.
It is useful to store the original pathname, because the program knows in
what context it is valid, and is useful for printing debug messages when
only the descriptor is known.
For things like stdin/out, pipes, sockets etc, the pathnames for these
could be "stdin", "stdout", "stderr", "pipe", "socket", etc.
| |
| Kamal R. Prasad 2005-05-30, 7:53 am |
|
William Ahern wrote:
> Kamal R. Prasad <kamalp@acm.org> wrote:
>
> That would really only make sense where all descriptors were addressable via
> the filesystem. In Plan9 everything is representated as an object in the
> filesystem, so not suprisingly they have a standard system call--fd2path().
>
Good for you. There isn;t an equivalent of that on UNIX.
> On Unix often times the majority of descriptors in a process are for pipes
> or sockets, neither of which have a "path" in the Unix sense.
For descriptors of type DTYPE_VNODE (using *bsd terminology), it should
be possible to maintain the path [or just provide an fd2path()]. There
is no denying that this piece of functionality is badly reqd and
missing.
regards
-kamal
| |
| Måns Rullgård 2005-05-30, 7:53 am |
| "Kamal R. Prasad" <kamalp@acm.org> writes:
> William Ahern wrote:
> Good for you. There isn;t an equivalent of that on UNIX.
>
>
> For descriptors of type DTYPE_VNODE (using *bsd terminology), it should
> be possible to maintain the path [or just provide an fd2path()]. There
> is no denying that this piece of functionality is badly reqd and
> missing.
Apparently nobody has needed it badly enough to implement it in the 30
years Unix has been around.
--
Måns Rullgård
mru@inprovide.com
| |
| Casper H.S. Dik 2005-05-30, 5:52 pm |
| "Kamal R. Prasad" <kamalp@acm.org> writes:
>I believe the OS ought to store the pathname which was passed to
>open() to get the fd (if it cannot provide the user with access to the
>namecache).
That's hardly sufficient; files get renamed, files get opened relative
to the current working directory, etc.
Both Solaris 10 and Linux do some form of bookkeeping to be able to
recover the pathnamem of a file.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Kamal R. Prasad 2005-05-30, 5:52 pm |
| The implementation does exist as namei() or vn_getfullpath() as may be
the interface defined to access the name cache. What Im getting at is
that it is not a std interface supported by the std and importantly, it
isnt accessible to userspace.
regards
-kamal
| |
| Kamal R. Prasad 2005-05-30, 5:52 pm |
| Absolute pathname as return value should be fine. Check out the
vn_fullpath() in freebsd.
regards
-kamal
| |
| Nils Weller 2005-05-30, 5:52 pm |
| In article <03uqm2-r2.ln1@wilbur.25thandClement.com>, William Ahern wrote:
> Kamal R. Prasad <kamalp@acm.org> wrote:
>
> That would really only make sense where all descriptors were addressable via
> the filesystem. In Plan9 everything is representated as an object in the
> filesystem, so not suprisingly they have a standard system call--fd2path().
>
> On Unix often times the majority of descriptors in a process are for pipes
> or sockets, neither of which have a "path" in the Unix sense.
System V (and SUS) provides functions to attach/detach STREAMS file
descriptors to/from the file system: fattach() and fdetach(). There is
also a convenient isastream() function you can use to determine whether
a file descriptor refers to a STREAM or not before trying to attach it
to the file system. This is of course of no use to you if you intend to
port to non-STREAMS-based systems such as Linux or the various BSD
derivatives (glibc at least makes an effort to compile and run code
using these functions by providing stubs that always return a negative
result), but it may otherwise take you relatively far if you only use
System V derivatives that implement those IPC facilities you're
interesting in atop STREAMS.
A final word of caution: While SVR4 implemented both (named) pipes and
sockets using STREAMS, few modern System V derivatives do this. Sockets,
for example, were traditionally implemented as a compatibility library
that uses STREAMS XTI, but many vendors chose to implement them
separately in order to improve performance (and XTI is obviously
irrelevant today.) And HP-UX, for example, by default does not even use
STREAMS for pipes. One (popular) system that can attach both pipes and
internet sockets to the file system is Solaris.
--
Nils R. Weller, Bremen / Germany
My real email address is ``nils<at>gnulinux<dot>nl''
.... but I'm not speaking for the Software Libre Foundation!
|
|
|
|
|