From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 16 Aug 2012 12:06:40 -0400 To: 9fans@9fans.net Message-ID: <384b49bb1ec181eab48f9b9920a12662@coraid.com> In-Reply-To: <20120816154130.GA551@polynum.com> References: <20120804152016.GB433@polynum.com> <20120805173639.GA395@polynum.com> <20120815173327.GA424@polynum.com> <20120815200949.4628BB85B@mail.bitblocks.com> <20120815212734.GA1190@polynum.com> <20120816034747.7FE5EB85B@mail.bitblocks.com> <20120816053428.GA427@polynum.com> <20120816154130.GA551@polynum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Multi-dimensional filesystem Topicbox-Message-UUID: aa2962f8-ead7-11e9-9d60-3106f5b1d025 On Thu Aug 16 11:44:01 EDT 2012, tlaronde@polynum.com wrote: > On Thu, Aug 16, 2012 at 09:40:22AM -0400, erik quanstrom wrote: > > > What is more bizarre, with my scheme, is how to implement the meaning > > > of ".."? If classical clients have to be able to be used, the server > > > must create a fake name (as the penultimate component of the > > > dirpath), that triggers the correct answer from the server. > > > > see defmnt.c:/^fixdotdotname for where this is handled by the kernel, > > not the file server. > > Well, I find cleanname (libc/port/cleanname.c) doing the .. dance with > compression. But nothing in the kernel proper.. cleanname is called by the function i indicated in devmnt. > > Except by allowing a new syntax .../{a,b,c,d}/foo meaning that foo has > a, b, c and d as parents, the only way I see things working with the > utilities and the ".." treatment is to insert a special name ensuring > that a ".." suppression leading to this name will trigger the correct > answer from the fileserver. this is already the case due to union directories (as bakul points out), and the solution has been widely discussed. - erik