On 31/05/11 01:14, James Youngman wrote: > On Tue, Apr 5, 2011 at 1:36 PM, Philipp Thomas <pth@xxxxxxx> wrote: >> GNU find will not recognize file systems of type autofs on newer Linux >> kernels as autofs entries are only listed in /proc/mounts and mountlist.c >> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that >> is /etc/mtab. >> >> After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils >> to use proc/mounts instead of /etc/mtab which fixed ou problem. >> >> Would gnulib accept the attached patch to mountlist.c? > > I don't know if this patch was accepted, but it shouldn't be. The > problem is that /proc/mounts has incomplete data for /. This will > break gnulib's mountlist, at least with the current form of the patch, > because mountlist will have an incorrect idea of the type of the root > filesystem. Here's an example showing the problem: > > ~$ cat tryit.sh > #! /bin/sh > f() { > echo "$1" > ( ls -l /etc/mtab; find / -maxdepth 0 -printf '%p %F\n' ) | > sed -e 's_^_ _' > } > > set -e > cd /etc > f "regular /etc/mtab" > > mv mtab mtab.old; ln -s ../proc/mounts mtab > f "with /proc/mounts" > rm mtab; mv mtab.old mtab > ~$ sudo sh tryit.sh > regular /etc/mtab > -rw-r--r-- 1 root root 1869 May 30 23:53 /etc/mtab > / ext3 > with /proc/mounts > lrwxrwxrwx 1 root root 14 May 31 01:12 /etc/mtab -> ../proc/mounts > / rootfs Well I didn't merge it, but for more generic reasons. It seemed like a bit of a layering violation to me, and I was unsure that other users of gnulib may need access to /etc/mtab specific stuff (on older systems). Here is related output on my Fedora 15 system which does link /etc/mtab -> /proc/mounts $ df / Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb2 13102208 3210896 9758244 25% / $ df -t rootfs Filesystem 1K-blocks Used Available Use% Mounted on rootfs 13102208 3210896 9758244 25% / $ find / -maxdepth 0 -printf "%p %F\n" / rootfs cheers, PÃdraig. -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html