GNU bug report logs - #12730
coreutils-8.20: FAIL: tests/du/bind-mount-dir-cycle.sh

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: g.esp <at> free.fr
Cc: 12730 <at> debbugs.gnu.org
Subject: bug#12730: coreutils-8.20: FAIL: tests/du/bind-mount-dir-cycle.sh
Date: Thu, 25 Oct 2012 23:06:45 +0200

g.esp <at> free.fr wrote:

> ----- Mail original -----
>> De: "Jim Meyering" <jim <at> meyering.net>
>> À: "g esp" <g.esp <at> free.fr>
>> Cc: 12730 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.