From: Lance Kibblewhite (lance@eco.twg.com)
Date: 03/24/97-12:25:40 PM Z
Message-Id: <3.0.1.32.19970324102540.00938b50@vishnu.eco.twg.com> Date: Mon, 24 Mar 1997 10:25:40 -0800 From: Lance Kibblewhite <lance@eco.twg.com> Subject: Re: FH -> pathname >On Mon Mar 24 00:48:23 1997, in <Roam.1.1.859164503.3219.brent@jurassic>, Brent Callaghan wrote: > >> >> Sure, it's possible and it's not expensive in terms of the amount >> of work the server needs to do, however on a cost/benefit tradeoff >> it is expensive if the server needs to stuff the fileid for the >> directory into every filehandle for the extremely rare case that >> someone wants to do a reverse FH -> filename mapping. > >If the Inode is already in the FileHandle of the directory of a LOOKUP >call, it would seem to me to take about two machine language >instructions to place it in the File Handle returned from the LOOKUP. >Is this so much to ask? You are talking here about Unix, but the proposal needs to work on other systems too. On VMS (as on UNIX and others), a file can have multiple paths. Does the path returned need to be the one through which the original access was granted? What if the file was renamed (or moved to another directory) since the lookup occurred? Should the original or new path be returned? What if the file has been deleted? It will not exist in any directory, but still remains on the disk until the final channel is removed. (Which is another problem with NFS not having an explicit CLOSE operation). >I guess you haven't been a system/network administrator who has >hundreds of people unable to do any work because some unknown machine >has been turned off. Ask any of them of the cost benefit and they >would kill for what I am asking for. I think this problem is better addressed by other improvements to the NFS and NLM protocols. If I was able to tell the administrator the name of a file that was still open after a PC has died, what would they be able to do? -- Lance
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:38 AM Z CST