2011/5/31 Karel Zak <kzak@xxxxxxxxxx>:
> On Tue, May 31, 2011 at 10:31:17AM +0100, PÃdraig Brady wrote:
>> 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
>
>
> ÂThat's strange, why for "/" it does not search in the file (mtab) in reverse
> Âorder?
>
> example A)
>
> Â Â Â Â # mount -t ext3 /dev/sda6 /mnt/test
> Â Â Â Â # mount -t ext4 /dev/mapper/kzak-home /mnt/test
>
> Â... so I have two entries for the same mountpoint:
>
> Â Â Â Â # grep /mnt/test /proc/mounts
> Â Â Â Â /dev/sda6 /mnt/test ext3 Ârw,relatime,errors=continue,barrier=0,data=ordered 0 0
> Â Â Â Â /dev/mapper/kzak-home /mnt/test ext4 rw,relatime,barrier=1,data=ordered 0 0
>
>
> Âthis is correct (ext4 is the second entry):
>
> Â Â Â Â # find /mnt/test -maxdepth 0 -printf '%p %F\n'
> Â Â Â Â /mnt/test ext4
>
>
> example B)
>
> Âthe same thing with root FS:
>
> Â Â Â Â # grep -E '(/dev/sda4|rootfs)' /proc/mounts
> Â Â Â Â rootfs / rootfs rw 0 0
> Â Â Â Â /dev/sda4 / ext3 Ârw,noatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
>
> Â... so I have two entries for the same mountpoint:
>
>
> Â Â Â Â # find / -maxdepth 0 -printf '%p %F\n'
> Â Â Â Â / rootfs
>
> Âwhy does it return the first entry? It seems like obvious bug. You
> Âhave to read entries in the mtab file in reverse order.
I find this claim most surprising, since getmntent is intended for use
on both /etc/mtab and /etc/fstab and it reads them forwards. As a
system administrator, I would consider it a bug for there to be a
duplicate entry in /etc/mtab, and if as a sysadmin I had actually
somehow put two similar entries into /etc/fstab, I'd expect mount(8)
to use the first match (and mount -a to use all matches).
> ÂAnyway, /proc/self/mountinfo is definitely more sexy... :-)
>
> Â ÂKarel
>
> --
> ÂKarel Zak Â<kzak@xxxxxxxxxx>
> Âhttp://karelzak.blogspot.com
>
--
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
