A suggestion: .... == ../../..

[Mark W. Eichin]

In article <75 at vertical.oz> greg at vertical.oz (Greg Bond) writes:
>This generalises: . = current dir, .. = parent dir, ... = grandparent etc.
>... . It would more usefully be done in the kernel
>routine (namei?) that maps names to inodes (where the symbolic links
>are traversed). ...
>Gregory Bond,  Vertical Software, Melbourne, Australia
>ACSnet: greg at vertical.oz,              UUCP: uunet!vertical.oz!greg

Side note: Athena runs 4.3BSD + NFS (U Wisconsin merge, VS2/VS2000
workstations). Directories . and .. are what you'd expect (current dir
and parent). If however you attempt to create/use a file named ... you
have problems[1]. If such a file exists, readdir will return it, but
stat of it returns ENOENT. If you try to create such a file, it will
appear not on the remote filesystem, but in the local one, in the
directory that the filesystem is mounted over[2].

Under the 4.3BSD+NFS on our IBM PC/RT workstations, ... works fine.

Anyone else seen this bug? It has been reported and filed here, I
don't know how far the report would have gone though.

				Mark Eichin
			<eichin at athena.mit.edu>
		SIPB Member & Project Athena ``Watchmaker'' 

 [1] The name can be anything matching the regexp \.\.\.* (string of
three or more dots.) This also is only valid for the top-level
directory of a mounted filesystem.
 [2] In the Athena environment, this is nasty, as mount usually is
preceded by mkdir, and thus umount is followed by rmdir. If the rmdir
fails (ENOTEMPTY) due to a ... file, certain importing programs will
detect the mount point, and report an error rather mount over existing
files.