Date: Mon, 06 May 2002 17:15:10 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Eric Jacobs <eaja@erols.com> Cc: fs@FreeBSD.ORG Subject: Re: Filesystem Message-ID: <200205070015.UAA15261@wellington.cnchost.com> In-Reply-To: Your message of "Fri, 03 May 2002 22:41:26 EDT." <PstOfc.3cd34a56.c67ea6@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Jacobs writes: > Bakul Shah <bakul@bitblocks.com> 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: > > > > <prefix>/<component>/.. == <prefix> > > <prefix>/<component>/../<suffix> == <prefix>/<suffix> > > /../<suffix> == /<suffix> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205070015.UAA15261>