Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!eichin From: eichin@athena.mit.edu (Mark W. Eichin) Newsgroups: comp.unix.wizards Subject: Re: A suggestion: .... == ../../.. Message-ID: <4715@bloom-beacon.MIT.EDU> Date: 19 Apr 88 14:03:45 GMT References: <75@vertical.oz> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: eichin@athena.mit.edu (Mark W. Eichin) Organization: Massachusetts Institute of Technology Lines: 33 Summary: ... is already *wierd* ... In article <75@vertical.oz> greg@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@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 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.