On Thursday 29 October 2009 04:47:52 Gilles Espinasse wrote:
> Selon Stuart Kemp <stuart_k...@hotmail.com>:
> > Yes, the app I was playing with does not call addmntent() or anything
> > else to explicitly manipulate /etc/mtab. But it should not have to, since
> > all of this mount-data is already available from the kernel (via
> > /proc/mounts); as such it seems redundant to even have /etc/mtab. The
> > problem could also arise using the "-n" option of mount(8). It would seem
> > logical to use a definitive set of information, given that it is readily
> > available i.e. get the mounted filesystems from /proc/mounts, rather than
> > the arbitrary data that may (or may not) be in /etc/mtab. And this
> > addresses a limitation in the current implementation.
> 
> There is sometime less informations in /proc/mounts than in /etc/mtab so
>  linking /etc/mtab to /proc/mounts may drive to issues.

yes, but that is being worked on.  long term plan is to have /etc/mtab be a 
symlink to /proc/mounts, and this issue will resolve itself.  i dont think 
this issue is worth sweating over, but that's just me ;).

> > And of course, using mount(8) with no arguments also has a "problem" in
> > that it lists the contents of /etc/mtab, rather than what is actually
> > mounted!
> 
> that could be considered as a feature when you are inside a chroot and
>  don't want to be distracted by what was done outside.

and i believe many /proc/ files can (and do) change behavior based on the root 
of the current process, perhaps including the list of mounted filesystems.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to