Messages in this thread | | | Date | Tue, 23 Apr 1996 21:08:58 +0200 | From | Andries.Brouwer@cwi ... | Subject | loop/mount - was: Re: /proc/misc has bad mode |
| |
Andries.Brouwer@cwi.nl wrote:
>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
| |