lkml.org 
[lkml]   [2001]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: symlink_prefix
    From viro@math.psu.edu Sun Jun  3 02:49:08 2001

On Sun, 3 Jun 2001 Andries.Brouwer@cwi.nl wrote:

> This evening I needed to work on a filesystem of a non-Linux OS,
> full of absolute symlinks. After mounting the fs on /mnt, each
> symlink pointing to /foo/bar in that filesystem should be
> regarded as pointing to /mnt/foo/bar.
>
> Since doing ls -ld on every component of every pathname was
> far too slow, I made a small kernel wart, where a mount option
> -o symlink_prefix=/pathname would cause /pathname to be prepended
> in front of every absolute symlink in the given filesystem
> (when the symlink is followed). That works satisfactorily.

Absolute symlinks... Dunno. _If_ we want that at all, we probably
want it on per-mountpoint basis. However, that opens a door to
_really_ ugly feature requests. E.g. "if symlink starts with
/foo - replace it with /mnt/bar, but if it starts with /foo/baz -
replace with /mnt/splat instead".

Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
/, /usr and /usr/spool filesystems for FOO OS. Now
mount /dev/a /mnt -o symlink_prefix=/mnt
mount /dev/b /mnt/usr -o symlink_prefix=/mnt
mount /dev/c /mnt/usr/spool -o symlink_prefix=/mnt
suffice.
I do not immediately see a realistic use for changing symlink
contents halfway.

I can see how to implement per-mountpoint variant. However, I'm
less than enthusiastic about the API side of that and about the
ugliness it will lead to. It smells like a wrong approach. And
no, I don't see a good one right now.

As for the API... How would you pass that option? Yet another
mount(2) argument?

What I did was: add a field `char *mnt_symlink_prefix;' to the
struct vfsmount, fill it in super.c:add_vfsmnt(), use it in
namei.c:vfs_follow_link(). Pick the value up by recognizing
in super.c:do_mount() the option "symlink_prefix=" before
giving the options to the separate filesystems.

[One could start a subdiscussion about that part. The mount(2)
system call needs to transport vfs information and per-fs information.
So far, the vfs information used flag bits only, but sooner or later
we'll want to have strings, and need a vfs_parse_mount_options().
Indeed, many filesystems today have uid= and gid= and umask= options
that might be removed from the individual filesystems and put into vfs.
After all, such options are also useful for (foreign) ext2 filesystems.]


Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:54    [W:0.097 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site