Hello, On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafbuddenha...@gmx.net wrote: > On Wed, Nov 04, 2009 at 10:10:43PM +0200, Sergiu Ivanov wrote: > > On Thu, Oct 29, 2009 at 06:37:54AM +0100, olafbuddenha...@gmx.net > > wrote: > > > > Well, I can't really give a final ACK without seeing the whole patch > > > in its final form... > > > > I'm sending the current version of the patch in this mail. > > Actually, it's not useful *this* time, as we are still discussing some > of the comments, and you haven't updated them yet -- so it can't be the > final version anyways :-) > > Perhaps you didn't expect the previous version to be final either -- if > this is the case, please pretend I never said anything about this ;-)
Well, I didn't expect the previous version to be final :-) But that's not a problem :-) I wonder, whether this version is final, though?.. > > > "most RPCs ont this node can be automatically carried out correctly" > > > is way too vague... It's not ever clear what "correct" means in > > > here, no what RPCs you mean. > > > > > > I think you should say that the mountee is set on a (clone of) the > > > unionfs root node, so that unionfs appears as the parent translator > > > of the mountee. AIUI that's the idea behind it, right? [...] > > Do you want to say that the goal of setting the mountee on a clone of > > the root node is to make unionfs appear as the underlying translator > > to the mountee? [...] > Exactly. OK. I've changed the comment accordingly. Namely, the sentence now looks like this: ``This node is based on the netnode of the root node (it is essentially a clone of the root node), because in this way unionfs appears as the underlying translator to the mountee.'' > I didn't want to use the term "underlying", because in the context of > unionmount, we always used it for the underlying filesystem of the > unionfs node; which, in the non-transparent case, is not the same as the > underlying filesystem of the mountee... But feel free to use this term, > if you think it causes less confusion than introducing completely new > ones :-) I think we should adopt some conventions in order to remove the ambiguity of the word ``underlying''. I'd suggest using ``underlying translator'' to specify the order of translators in a stack, ``underlying filesystem'' for the real underlying filesystem, and ``unioned directory'' for one of the components of the union managed by unionfs. I'm strongly inclined to consider the term ``underlying filesystem'' used for a unioned directory to be unwieldy chosen: firstly, unionfs is not operating on filesystems, and secondly, the directories it operates on are not underlying to it. > > I'm not sure whether this is a feature or a misbehaviour > > I don't think it's a bug -- doesn't seem very likely that nobody would > have noticed such a fundamental bug all this time... Yeah, that's my opinion, too. > But feel free to investigate this further, reading some relevant POSIX > man-pages, and/or the server code implementing file creation. Or perhaps > it would be easiest to try reproducing it with standard POSIX functions, > both on Hurd and on Linux... Yes, this is what I considered doing, but haven't yet found the time. Regards, scolobb
