All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stef Bon <stef@bononline.nl>
To: Ian Kent <raven@themaw.net>
Cc: autofs@linux.kernel.org
Subject: Re: How to determine a path is a mountpoint.
Date: Fri, 19 Feb 2010 00:18:37 +0100	[thread overview]
Message-ID: <201002190018.37820.stef@bononline.nl> (raw)
In-Reply-To: <4B7BFC44.4050706@themaw.net>

On Wednesday 17 February 2010 15:25:08 Ian Kent wrote:

> 
> And I will check the implementation and get back with specific
> behaviours, if this is what you need.
> 
> Don't forget that if the kernel doesn't support the mount check ioctl
> you will need to use something like what is done in
> lib/mounts.c:is_mounted() and call something like
> lib/mounts.c:table_is_mounted() to scan /proc/mounts. It does this when
> it sees the kernel doesn't support the new function. That is when it
> sees that the struct ioctl_ops ismountpoint field is null (because there
> is no ioctl entry point for it).
> 
> Ian

OK,

I know that I need something else when the kernel does not support the ioctl check. 

Maybe I should have been more clear in what I want.
I'm afraid I have totell you something about my setup, although you don't need to understand it. Please do not forget just learned C and not "home" in the 
autofs code and construction.

I'm using a very simple map file:

*            -fstype=md5key :/&

that's it!
It passes every key to the mountcommand of the nonexistant md5key  filesystem:
/sbin/mount.md5key

which is a wrapper for other (real) mount commands. The automounter just let this happen what is a pretty nice thing!

Now the mountpoint where this map is assigned to depends to the user, the line
in the auto.master looks like:

/mnt/mount.md5key/sbon/mount       /etc/autofs/auto.md5key    MD5KEY_USER=sbon

Now this directory is not to be accessed directly by the user, but through a fusemodule I'm working on. In short, it points to directories (keys) in the
/mnt/mount.md5key/sbon/mount directory, which are one level deep. Every key is actually the md5sum of a record (I call them resource records) about a 
resource, local(USB) or remote (CIFS, FTP, SSH). 

Now in the autofs managed directory 

/mnt/mount.md5key/sbon/mount 

only those directories exist of resources actually mounted! If I access a SMB share in my connection tree, my call is redirected to the proper md5key 
directory in /mnt/mount.md5key/sbon/mount, making the automounter mount the share:

mount | grep /mnt/mount.md5key/sbon

//SCLFS20091030/video on /mnt/mount.md5key/sbon/mount/e23e33a53d5d08ad8f0425de4edd9309 type cifs (rw,mand)


and when I do /bin/ls -l /mnt/mount.md5key/sbon/mount:
total 0
drwxr-xr-x 10 root root    0 2010-02-09 12:11 e23e33a53d5d08ad8f0425de4edd9309

when I enter other shares these appear as well. When unmounted, the directories disapear. Logic, you might say, but this is crucial.

My fusemodule is an overlay fs, which mirrors another directory under the directory under which it's mounted, and does some changes.

Now how does my module know which share is mounted when building an directory overview with readdir and applications like Dolphin
are searching for a .directory file. The call for this .directory file in the target is intercepted by my fuse module, cause otherwise
this call will also make the automounter mount the share, while only the .directory is looked up.

Now like I've said before, I cannot do a stat of the target key directory, cause this will make the automounter to mount the share.
It's possible to make my fuse module to read the contents of /mnt/mount.md5key/sbon/mount, and check the key to be investigated
is in this directory. I haven't tested this, but it should work.

Right now I looking for a way the automounter can give the answer.
It looks like the dev_ioctl_ismountpoint return -1 for the case the share is not mounted, and *mountpoint is equal to 0.
When mounted, another filesystem is mounted, so *mountpoint is DEV_IOCTL_ISMOUNTED | DEV_IOCTL_IS_OTHER.

So probably I have to create a exampleprogram doing this, with the path as a parameter.

Stef Bon

  reply	other threads:[~2010-02-18 23:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-15 21:53 How to determine a path is a mountpoint Stef Bon
2010-02-16  3:04 ` Ian Kent
2010-02-16 13:20   ` Stef Bon
2010-02-16 17:29     ` Ian Kent
2010-02-17 12:43       ` Stef Bon
2010-02-17 14:25         ` Ian Kent
2010-02-18 23:18           ` Stef Bon [this message]
2010-02-19  3:57             ` Ian Kent
2010-02-19 14:11               ` Stef Bon
     [not found]                 ` <201002211428.39077.stef@bononline.nl>
2010-02-22  3:54                   ` Ian Kent
2010-02-22 16:30                     ` Stef Bon
2010-02-22 16:38                       ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201002190018.37820.stef@bononline.nl \
    --to=stef@bononline.nl \
    --cc=autofs@linux.kernel.org \
    --cc=raven@themaw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.