bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Meyering
Subject: bug#12730: coreutils-8.20: FAIL: tests/du/bind-mount-dir-cycle.sh
Date: Fri, 26 Oct 2012 13:57:29 +0200

address@hidden wrote:
> ----- Mail original -----
>> De: "Jim Meyering" <address@hidden>
>> À: "g esp" <address@hidden>
>> Cc: address@hidden
>> Envoyé: Jeudi 25 Octobre 2012 23:06:45
>> Objet: bug#12730: coreutils-8.20: FAIL: tests/du/bind-mount-dir-cycle.sh
>>
>> address@hidden 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]