> >> Does it mean to mount F immediately over D, in spite of anything that > >> might be stacked above D right now? Or does it mean to throw F onto > the > >> stack which is currently sitting over D? Your analysis assumes it's > the > >> former, whereas what Linux does is consistent with the latter. > > > >In fact those two are indistinguishable. What linux does is an > >internal implementation detail. > > Then you must have misunderstood what I meant to say, because I didn't > touch on Linux implementation at all;
Right, sorry. > I'm talking only about what a user sees (distinguishes). I say a > user perceives a stack of mounts over a directory entry D. A lookup > sees the mount which is on top of the stack. One could conceivably > 1) add a mount to the middle of that stack -- above D but below > everything else, such that it isn't visible until everything above > it gets removed, or 2) add the mount to the top of the stack so it's > visible now. OK. One problem with 1) is that it breaks the assumption that an 'mount X; umount X' pair is a no-op. > >Well, mounting over '.' may not be perfect in the mathematical sense > >of namespace operations, but it does make some practical sense. I bet > >you anything that some script/tool/person out there depends on it. > > It wouldn't surprise me if someone is depending on mount over ".". But > I'd be surprised if someone is doing it to a directory that's already been > mounted over (such that the stacking behavior is relevant). That seems > really eccentric. You are probably right, but one can never know. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
