NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/unix/programm/4252

Internet Message Format | 1992-08-12 | 2.0 KB

Xref: sparky comp.unix.programmer:4252 comp.unix.internals:1680 comp.sys.hp:9202
Newsgroups: comp.unix.programmer,comp.unix.internals,comp.sys.hp
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bwdls61!bnr.ca!mleech
From: [e-mail] (Marcus Leech)
Subject: Re: inode to filename
Message-ID: <[e-mail]>
Sender: [e-mail] (Use Net)
Nntp-Posting-Host: bwdlh529
Organization: Bell-Northern Research, Information Techology Division
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 12 Aug 1992 14:40:32 GMT
Lines: 25

In article <[e-mail]>, [e-mail] (Alan Barclay) writes:
|> I don't see it as a weakness, if there was a one to one relationship
|>
|>  [MS-DOS references delated].
|> I don't see the need to refer to a file from a inode number anyway,
|> the most common you can get a inode number is though stat or fstat,
|> and presumably you knew the filename in the past.
A common reason for wanting to do this is to determine what's going on in
  your system.  Which processes have which files open, etc.  This *is*
  useful, and UNIX has traditionally (and continues to be) weak in the areas
  of effective system management mechanisms.

The traditional argument for not storing such information in the kernel
  has been "too much space".  Memory is now quite cheap, and with clever
  data structures, you don't pay that much for keeping filename<--->process
  mappings around.  If, for example, you recognize that there is a very
  high degree of shared name space, you can take advantage of that fact to
  dramatically reduce the storage requirements.

In this *particular area*, VMS is better.

--
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
[e-mail]                  P.O. Box 3511, Stn. C   |are my own, and not
[e-mail]             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs