#19 support for 'mount -v' and 'mount/umount <servicename>'

[Struan Bartlett]

For future ease of use I had put a line in my fstab:

lufs /mnt/lufs lufs
nosuid,owner=0,rw,nosuid,fs=ftpfs,host=mysite,username=myname,password=xyzzy,channels=1
0 0

I kept trying to mount it with 'mount -av' but this
failed with a message:

Usage: /sbin/mount.lufs none <mount-point> -o [options,
...]

Sticking in a bash script in place of mount.lufs I
discovered it's being called like this (single quotes
are mine and separate args)

'lufs' '/mnt/lufs' '-v' '-o'
'rw,nosuid,owner=0,fs=ftpfs,host=danplesch.net,username=lovelyrockboy-619622,password=2qG)ms[5,channels=1'
'' '' '' ''

So looked like mount.lufs needed to be able to cope
with -v as the third argument. This patch lets lufsd to
cope with -v.

Incidentally, while I was doing this, it seemed to me
that the code didn't take full advantage of what
daemon.c calls the 'service' argument to mount.lufs.
Even though it is passed to lufsd, lufsd ignores it
when execing lufsmnt. lufsmnt then calls mount() with
"none" as its first parameter and puts the
sub-filesystem-type (e.g. ftpfs) into mtab. This seems
to prevent the user from taking advantage of certain
useful functionality, as I will try to explain.

With tmpfs, I mount two tmpfs filesystems as follows:

# mount -v -t tmpfs t1 /mnt/t1
t1 on /mnt/t1 type tmpfs (rw)
# mount -v -t tmpfs t2 /mnt/t2
t2 on /mnt/t2 type tmpfs (rw)
# grep tmpfs /etc/mtab
t1 /mnt/t1 tmpfs rw 0 0
t2 /mnt/t2 tmpfs rw 0 0

Now for the useful functionality:

# umount t1
# umount t2

Similarly, if put in fstab:

t1 /mnt/t1 tmpfs size=768k 0 0
t2 /mnt/t2 tmpfs size=512k 0 0

Then you can enter:

# mount t1
# mount t2
# umount t1
# umount t2

So, in conclusion, insisting on 'none'/'ftpfs' being
the service name (in the call to mount/in mtab
respectively) seems to needlessly limit existing
functionality in cases where more than one ftpfs mount
is being used.

This patch also makes lufsmnt take three arguments
(service, mountpoint, opts) and use the service
argument in the call to mount() and for the mtab file.

I've roughly tested the resulting code and the only
problem I've got is that after a 'mount -av' mount
reports 'nothing was mounted', which I don't
understand, because mount.lufs seems to be returning to
mount the correct code (0). Apart from this, seems so
far, so good. With this in fstab:

myftp1 /mnt/lufs1 lufs
nosuid,owner=0,rw,nosuid,fs=ftpfs,host=mysite1,username=myname1,password=xyzzy1,channels=1
0 0
myftp2 /mnt/lufs2 lufs
nosuid,owner=0,rw,nosuid,fs=ftpfs,host=mysite2,username=myname2,password=xyzzy2,channels=1
0 0

Now I get:

# mount -v myftp1
myftp1 on /mnt/lufs1 type lufs
(rw,nosuid,owner=0,fs=ftpfs,host=mysite1,username=myname1,password=xyzzy1,channels=1,server_socket=/tmp/lufsd720987849,server_pid=26381)
# mount -v myftp2
myftp2 on /mnt/lufs2 type lufs
(rw,nosuid,owner=0,fs=ftpfs,host=mysite2,username=myname2,password=xyzzy2,channels=1,server_socket=/tmp/lufsd899122597,server_pid=26389)
# umount myftp1
# umount myftp2

Problem is, it may break users' existing systems if
they rely on lufsmnt accepting the original arguments.
I'd propose this be dealt with by renaming lufsmnt to
e.g. lufsmnt.new and providing a wrapper script lufsmnt
that expects the original argument set, but which execs
lufsmnt.new.

Please see the attached patch file for both code
modifications.

Someone might like to take this further.

[Struan Bartlett]

Patch to lufs-0.9.7 to allow 'mount -v', and 'mount/umount <servicename'