Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> > The pointer to the related "lofs" sourcecode explains how it works and why it
> > works as expected on Solaris.
> >
> > Note that a mount point relative absolute path needs to be evaluated against
> > the real original (first) mount and not against the second loopback mount.
>
> Except that unlike your lofs, bindings are symmetrical. I.e. there is no
> such thing as "real" mount - they are simply mounts refering to various
> subtrees of given fs. And mount --bind /foo/bar /baz does *not* render /foo
> impossible to umount. Not to mention that even on Solaris there's such
> thing as chroot and you really don't want to open that can of worms...
lofs has been introduced with NSE, the first project oriented revision control
system (based on SCCS). lofs at that time was used to create chrooted tailored
environments and of course, symlinks are important in such environments.
Absolute symlinks in such an environment either point to a local equivalent or
they do not point to anything. Both is accepted behavior as this does not
differ from the non-chrooted case.
Relative symlinks that point outside the chrooted environment are evaluated
according to the rules for symlinks and for the root directory.
I see no can of worms here.
Let me look at the "binding"... I cannot see any advantage compared to loopback
mounts. Do you know such an advantage?
If you allow to umount the original mount when there is another
(non-overlapping) mount, then you of course have a problem with absolute mount
point related symlinks. Given the fact that the Rock Ridge filesystem is older
than Linux and that RR introduced mount point related absolute symlinks, isn't
this bind mount something that could have been avoided?
Well, I have to admit that Solaris does not implement mount point related
absolute paths in symlinks with Rock Ridge even though it could be done.
Seems like I should write than code ;-)
Jörg
--
EMail:joerg@xxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
js@xxxxxxxxxxxxxxx (uni)
joerg.schilling@xxxxxxxxxxxxxxxxxxx (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
