Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.unix.wizards Subject: Re: symbolic links are a botch Message-ID: <5985@brl-smoke.ARPA> Date: Sun, 14-Jun-87 00:15:34 EDT Article-I.D.: brl-smok.5985 Posted: Sun Jun 14 00:15:34 1987 Date-Received: Sun, 14-Jun-87 19:38:53 EDT References: <2629@ulysses.homer.nj.att.com> <5962@brl-smoke.ARPA> <2075@emory.UUCP> <5984@brl-smoke.ARPA> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 16 Keywords: file system, file name resolution In article <5984@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: >... on the grounds that it adds structural complexity. My counter-argument >is that the strict directory hierarchy is such an important idea that it ... Upon re-reading my previous posting, I noticed that I didn't make clear what to me is the telling point: The Korn handling of ".." makes the file system appear at least LOCALLY hierarchical, even though GLOBALLY it's not. Since ".." normally has use only for such local behavior, Korn's approach seems appropriate for it. The argument someone supplied about the contents of a symlink being "../foo" doesn't seem relevant if the "../foo" is interpreted relative to the actual current directory containing the symlink; the pathname involved in the open() (or stat() or whatever) should not be affected by the contents of any symlinks encountered along the way. Proper local handling of .. within a symlink is thus different from proper handling of .. in the user pathname context.