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 21:37:08 >> Objet: bug#12730: coreutils-8.20: FAIL: tests/du/bind-mount-dir-cycle.sh >> > ... >> >> It sounds like you have confirmed my conclusion. >> When you use a symlink, /etc/mtab contains a line for the a/b mount >> and the mount-listing loop in fill_mount_table inserts an entry for >> a/b. >> Later, when we search that table for the inode of "a/b", we find >> that entry and know that it's a bind-mount, so issue only the minor >> warning, rather than the "DISK CORRUPTION" warning. >> >> With your regular mtab file, it contains no such a/b line, and >> the mount-listing loop in fill_mount_table inserts no entry for a/b. >> Later, when we search that table for a/b's inode, we find no entry >> and have to report the more serious error. >> >> > 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? Can you compare the contents with those of /proc/mounts? 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.
