On Wed, Apr 01, 2015 at 02:04:27PM +0200, Ruediger Meier wrote:
> ts_init_subtest "umount"
> [ -d "$TS_MOUNTPOINT" ] || mkdir -p $TS_MOUNTPOINT
> $TS_CMD_MOUNT $DEVICE $TS_MOUNTPOINT &> /dev/null
> OLD_SUM=$(mtab_checksum)
> (
> ulimit -f 1
> $TS_CMD_UMOUNT $TS_MOUNTPOINT &> /dev/null
> ) &> /dev/null
> NEW_SUM=$(mtab_checksum)
> $TS_CMD_UMOUNT $TS_MOUNTPOINT &> /dev/null
> [ $NEW_SUM = $OLD_SUM ] && echo "OK: mtab unmodified by umount" >>
> $TS_OUTPUT
> ts_finalize_subtest
> ...........
>
> I do not fully understand what is expected. Obviously the first "umount"
> should NOT modify /etc/mtab. But should it umount or not, or doesn't
> matter? Why we call a second umount then?
I guess the second umount is just copy & past (from mount test) and
it's there to be sure that the device has been really unmounted (and
this is unnecessary because ts_device_deinit() calls umount too).
> The problem is that in case that the first umount works we are leaving
> the test with a broken mtab file. This is not nice and also problematic
> because later tests may find a mounted /dev/loop0 in /etc/mtab.
It would be probably better to replace the second umount with "umount
--fake" to only remove entry from mtab.
> Should we restore the original mtab? I guess it's a bit unsafe to copy
> back a backed up one. Or is there a way to "repair/sync"
> from /proc/mounts.?
Don't use /proc/mounts. It's bad idea as the files maybe very different.
use the --fake or you can try to redirect libmount to use non-standard
mtab by env. variable LIBMOUNT_MTAB=, but it will increase complexity
of the test.
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
