g....@free.fr wrote: > ----- Mail original ----- >> De: "Jim Meyering" <j...@meyering.net> >> À: "g esp" <g....@free.fr> >> Cc: 12...@debbugs.gnu.org >> Envoyé: Jeudi 25 Octobre 2012 23:06:45 >> Objet: bug#12730: coreutils-8.20: FAIL: tests/du/bind-mount-dir-cycle.sh >> >> g....@free.fr wrote: >> > ... >> > I don't understand why you conclude that a/b is missing in regular >> > mtab case. >> > To give shorter lines easier to read >> > [chroot-i486] root:/usr/src/coreutils-8.20$ cd / >> > [chroot-i486] root:/$ mkdir -p a/b >> > [chroot-i486] root:/$ mount --bind a a/b >> > [chroot-i486] root:/$ cat /etc/mtab >> > /dev/disk/by-uuid/7a235d64-5d04-41ac-a959-70465eb74fc8 / ext3 >> > rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0 >> > /a /a/b none rw,bind 0 0 >> > >> > I see a/b here and umount know how use that a/b entry >> > [chroot-i486] root:/$ umount a/b >> > [chroot-i486] root:/$ >> > >> > what is really missing? >> >> In the above, is /etc/mtab a regular file? > yes >> Can you compare the contents with those of /proc/mounts? > > essentially > -/dev/disk/by-uuid/7a235d64-5d04-41ac-a959-70465eb74fc8 /a/b ext3 > rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0 > +/a /a/b none rw,bind 0 0 > >> >> It might be useful to make fill_mount_table print each >> mnt_ent->me_devname >> for which it calls hash_insert. >> >> It sounds like the entry for a/b is being inserted when /etc/mtab >> points to /proc/mounts, but not in the other case. >> > Yes, in that case, this line is exclude by the !mnt_ent->me_dummy condition. > The reason is that the fs value is 'none' and that qualify for the dummy list.
I'm not sure your case would be considered mainstream enough to merit changing mountlist.[ch], but that is a possibility: If we went that route, we'd change how me_dummy is set so that it takes account of your case. For example, we might add a boolean "is_bind_mount" parameter to ME_DUMMY macro, so that when me_type is "none" and is_bind_mount is true, ME_DUMMY would evaluate to false, rather than to true. The only tricky part would be robustly determining whether "bind" is in mnt->mnt_opts. Care to write the patch?
