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
signature.asc
Description: This is a digitally signed message part.