>Yes, /etc/mtab has
> /tmp/fdimage /mnt msdos rw,loop=3D/dev/loop0,blocksize=3D1024 0 0
> /dev/cdrom /cd iso9660 ro,noexec,nosuid,nodev,unhide 0 0
>where /proc/mounts has
> /dev/loop0 /mnt msdos rw 0 0
> /dev/cdrom /cd iso9660 ro,noexec,nosuid,nodev 0 0
>
>It follows that /proc/mounts cannot yet replace /etc/mtab -
>some mount options are invisible in /proc/mounts.
Well, I never use "unhide"
Of course the `unhide' was just an example. There are oodles of
mount options (for msdos: check, conv, uid, gid, umask, fat, blocksize,
debug, and even dots, nodots, dotsOK, showexec, sys_immutable -
maybe I forget some, and similarly for other file system types).
One wants to see these [sometimes it is important to know whether
this CDROM was mounted with conv=auto or conv=binary, or whether
this ext2 fs was mounted with bsdgroups or sysvgroups].
So, /proc/mounts must have all mount options, not just the booleans
in mountflags. This means that /etc/mtab remains necessary for the
time being.
I patched my loopback device and my mount binary
so that closing or unmounting /dev/loop? automatically
disassociates the device from the file.
No patch required, that is the default behaviour of the current mount.
IMHO it is a mistake for /dev/loop? to remember its association
to a file after it's closed.
If you do
mount file /dir -o loop
...
umount file [or: umount /dir]
then afterwards the loop device that was used implicitly
is no longer in use.
If you explicitly associate /dev/loop3 with some file, then
you also have to explicitly disassociate it again
(probably both times using losetup). This use is discouraged,
but is left for backward compatibility.
Andries