[lkml]   [1996]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectloop/mount - was: Re: /proc/misc has bad mode 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.


 \ /
  Last update: 2005-03-22 13:37    [W:0.025 / U:1.556 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site