Gábor S. <otnaccess@xxxxxxxxxxx> wrote:
> > Well, actually for removable media it makes more sense than having
> > links starting with /. You never know where your filesystem is going to
> > be mounted or on which system so such links are often going to point to
> > some non-existent place. For backups it does not matter but if you
> > actually need to use those symlinks it makes a lot of sense. But
> > relative symlinks are probably more portable solution in that case...
> I agree with all these points. Although the feature seems to be useful, I
> don't know any other filesystem (to be honest I know the features of a few
> of them only) which supports symbolic links relative to the root of the
> volume. So to create such a UDF volume a special application is needed.
> That's why most people would rather opt for relative symbolic links for such
> a purpose.
This idea has obviously been imported from the older Rock Ridge filesystem that
uses a very similar method to deal with symbolic links.
Mkisofs currently does not support absolute symlinks relative to the mount
point but I did recently write a portable replacement for the Solaris
"resolvepath()" syscall to fit the needs of a project oriented distributed SCCS.
With this function it is possible to check whether a symlink points to
something that is outside the ISO media. So in future, it would be possible to
convert absolute symlinks that point to something inside the ISO into a mount
point based absolute path, as well as to flag symlinks that do not point to an
object inside the ISO.
And BTW: given the fact that Linux supports programs like "df", I would guess
that it is possible to do that mapping. Note that unless you do something
really weird (which would be in conflict with the POSIX standard), you always
know the vfs structure for a file and a vfs structure of course has an
associated mount point. Given the fact that in an FS that does not support
hard links to directories (UDF does not, so you are on the easy side) there is
exactly one way to traverse the directory tree upwards, As a result, there is
always exactly one mountpoint related to any leaf fs object.
AFAIK, Linux does getcwd() in kernel as Solaris does, so it should be possible
to get the path for a mount point, in case that path was not kept during the
mount(2) operation.
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
