[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mtab (was: Re: path+file_name from port or process info?

From: Marcus Brinkmann
Subject: Re: mtab (was: Re: path+file_name from port or process info?
Date: Tue, 23 Jul 2002 14:42:07 +0200
User-agent: Mutt/1.4i

On Mon, Jul 22, 2002 at 10:31:53PM -0400, David Walter wrote:
> If this is to  maintain compatibility  with Posix/UNIX, shouldn't  the
> mount command manage the  insertion of records?  If  that is  the case
> the rest of my issues disappear as well.

This is a point I didn't address well in my last mail, sorry.

We _could_ make "mount" and "umount" responsible for mtab.  In this case, we
wouldn't need an mtab translator at all!  But in this case, we must also
forbid the user to use settrans and fsysopts to manipulate the translator.

This locks the user in the Unix world, which is bad and unnecessary.
It would provide a somewhat useful feature only in the Unix world but
not in the Hurd world (a working df :).

We can do much better than that, and it is not too hard to do.  First, we
can move the responsibility to register the filesystem to the filesystem
itself.  This will make it work with passive translators, with translator
death, and will work with settrans and fsysopts.  mount is then just again a
wrapper around the corresponding features in the Hurd.  This will make the
mtab feature more useful.

Let me try to wrap up the state of the discussion:

Translators should check if they run suid or sgid, if no, they should check
if $MTABSERVERS is set and use that.  If it is not set, or they run
suid/sgid, and they run as root, they should use _PATH_MOUNTED if it exists.
If they run as normal user, they should use $HOME/.mtab (or something
similar) if it exists.  They should do whatever is necessary to register
themselves with this filesystem (I think writing a single line with the path
is the thing to do -- the rest can be derived by mtab).

df should check _PATH_MOUNTED and $HOME/.mtab (or something similar) and
concatenate the output.

The user should be able to override (and change at runtime) the path that
the translator registers with mtab by setting --mtab PATH.  It should be
able to suppress registration (unregister at runtime) with --no-mtab.

I think so far we agree (as soon as you forget about the mount thing :)

Now, what about the following questions:

* Can a translator determine the path to be registered with mtab

* If yes, which translators should do this by default, unless --no-mtab is

I think the _hurd_canonicalize_dirname_internal function is worth trying
out.  It might just be what we want in the normal case, which will certainly
be 99% of the cases.  The rest can use --mtab explicitely.  Also, if you
move the filesystem, you need to kick off a change to mtab manually[2].

[2] Unless you go for a very complicated and somewhat expensive solution and
request dir notification messages on all dir nodes that are in your path, and
then act on rename operations properly.  Which is, again, not guaranteed to
work, but would be the honest attempt approach at doing the right thing.
However, I think this is overkill, for the following reason:  The
things you want in mtab are the permanent filesystems like /, /mnt, /cdrom,
etc, which usually are not moving around a lot.  The more dynamic filesystems
should not be registered with mtab anyway.


`Rhubarb is no Egyptian god.' GNU
Marcus Brinkmann              The Hurd

reply via email to

[Prev in Thread] Current Thread [Next in Thread]