home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16664 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.7 KB
  1. Xref: sparky comp.lang.c:16664 comp.unix.questions:13513
  2. Path: sparky!uunet!usc!elroy.jpl.nasa.gov!swrinde!emory!sol.ctr.columbia.edu!spool.mu.edu!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse
  3. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  4. Newsgroups: comp.lang.c,comp.unix.questions
  5. Subject: Re: name of file descriptor
  6. Message-ID: <1992Nov17.125931.7731@thunder.mcrcim.mcgill.edu>
  7. Date: 17 Nov 92 12:59:31 GMT
  8. References: <1992Nov16.122835.16126@alf.uib.no>
  9. Followup-To: comp.unix.questions
  10. Organization: McGill Research Centre for Intelligent Machines
  11. Lines: 26
  12.  
  13. In article <1992Nov16.122835.16126@alf.uib.no>, singg@alf.uib.no (Kurt George Gjerde) writes:
  14.  
  15. > How can I get the filename from a filedescriptor, on Unix??
  16.  
  17. This is a UNIX question, not a C question, and I'm therefore
  18. crossposting to comp.unix.questions and redirecting followups there.
  19.  
  20. In general, you can't.  The file descriptor may not be connected to a
  21. file (it may be a pipe or (other) socket or TLI stream or a device or
  22. maybe something else).  Even if it is a file, the file may have no
  23. names any longer, or it may have multiple names.  Even if it has at
  24. least one name, there may be no name by which it is accessible to your
  25. process or possibly even other processes.  And even if you assume it
  26. has a name that you could use to refer to it by, there is no way to
  27. find any such name short of a full scan of all filesystems, which can
  28. take a *long* time.
  29.  
  30. You're usually best off writing wrappers for open/close (or
  31. fopen/fclose if you're using stdio) that remember filenames.  The major
  32. case where this doesn't work is when you're dealing with redirection to
  33. or from files, in which case you're pretty much out of luck.
  34.  
  35.                     der Mouse
  36.  
  37.                 mouse@larry.mcrcim.mcgill.edu
  38.