From owner-freebsd-fs Mon May 6 17:15:24 2002 Delivered-To: freebsd-fs@freebsd.org Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by hub.freebsd.org (Postfix) with ESMTP id 0E89637B403 for ; Mon, 6 May 2002 17:15:14 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by wellington.cnchost.com id UAA15261; Mon, 6 May 2002 20:15:11 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200205070015.UAA15261@wellington.cnchost.com> To: Eric Jacobs Cc: fs@FreeBSD.ORG Subject: Re: Filesystem In-reply-to: Your message of "Fri, 03 May 2002 22:41:26 EDT." Date: Mon, 06 May 2002 17:15:10 -0700 From: Bakul Shah Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Eric Jacobs writes: > Bakul Shah wrote: > > Plan9 does ".." right. The same can be done in Unix by > > storing the rooted path in the kernel for a process'es > > current working dir. and by following some path rewrite > > rules: > > > > //.. == > > //../ == / > > /../ == / > > Those rules aren't valid on the account of syntax alone. You would > have to know which components are symbolic links. And once you take > into account symbolic links, you have essentially what namei does > anyway. Actually the main reason for wanting these rules is to remove the surprise associated with symbolic links. Of course, by now people have accepted that bar/foo/.. may land you not in bar/ but somewhere totally different if foo is a symlink and some have perhaps even built programs that rely on that fact.... Think about it this way: With symlinks and mounts you can have more than one __path__ to a file or directory. ".." merely get you back one component on that particular path. This works without a surprise with mounts but not symlinks. For example, # mount server:/usr/src /usr/src # cd /usr/src # cd .. # /bin/pwd /usr # umount /usr/src # rmdir src # ln -s /host/server/usr/src /usr/src # cd /usr/src # cd .. # /bin/pwd /.amd_mnt/server/host/usr In effect with symlinks you can't retrace the path you took; you have to go the long way back. Read Rob Pike's paper "On getting dot-dot right" for a better explanation. > I think what Terry Lambert was saying was that since hard-linking > directories isn't allowed anyway, there's no need to refcount them, > except for the subdirectory counting tricks. Yes. > If you can handle access considerations yourself, one creative solution > might be to use getfh(2) and fhopen(2) and store the file handles however > way you want. This bypasses the kernel lookup entirely. Yes, you can always work around kernel limitations. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message