Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.misc
Subject: Re: ascending above top of file system
Message-ID: <1991Mar7.033806.2488@athena.mit.edu>
Date: 7 Mar 91 03:38:06 GMT
References: <5311@umbc3.UMBC.EDU>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 31


  The algorithm (simplified to allow chdir'ing; it could be written without
it, in order to use it as a library function that doesn't have to fork to work
properly) looks something like this (starting with an accumulated path of ""):

1. stat(".")
2. stat("..")
3. If the devices of "." and ".." *and* the inodes of "." and ".." are equal,
   then:
   a. append "/" to the beginning of the accumulated path
   b. return the accumulated path.
4. opendir("..")
5. for each file (readdir("..")), do:
   a. stat("file")
   b. If the device and inode of "file" is equal to the device and inode of
      "." retrieved in step (1), then:
      i. append "/" to the beginning of the accumulated path
      ii. append "file" to the beginning of the accumulated path
      iii. chdir("..")
      iv. goto (1)
6. signal an error, indicating that no file in ".." matching "." was found

  The algorithm you described is wrong for two reasons: (1) It compares only
inodes, and not both inodes and device numbers; and (2) It forgets about going
through the ".." directory looking for an entry matching ".".

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710