>> 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; 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. >The semantics are simple: if you >mount over a directory, that mount will be visible (no matter what was >previously visible) on lookup of that directory. So in my terms, Linux adds to the top of the stack, not to the middle. Note that saying this is stronger than what you say above, because it tells you not only that the mount is visible now, but when it will be visible in the future as people do mounts and unmounts. >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. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - 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
