On Wed, 10 Nov 1999, H. Peter Anvin wrote:
> Urban Widmark wrote:
> >
> > Yes ... something like what devfs does? Creating directories for each
> > server it finds (each server it's userspace daemon finds), creating
> > subdirectories for each share (when someone accesses the dir).
>
> That's what autofs does. That far it is easy. The hard part is that a
Ok, it can do that for both the server and the share "level". Good.
> stat() is an *access*... and so, it should logically mount the share.
Yes, normally. But typically you are perhaps not that interested in that
info on the share? The thing you end up mounting you want updated with the
correct times etc but the rest you may not care about. This will be an
additional visible difference between the automounted directories and
local directories, so it will probably break some type of usage (so it
must be an optional behaviour).
> Problem. Big problem. The hard part with browsing is to spoof the
> stat() so that it doesn't mount every single share on "ls -l" or by
> pointing a GUI browser at it.
stat() -> fs/stat.c:sys_newstat() ? Then we have (2.2.13):
dentry = namei(filename);
error = do_revalidate(dentry);
namei finds the dentry of the dir by doing lookup_dentry, and that reads
the inode (as far as I can tell). If you do this as a "browsefs" you could
fill the inode of the share (the autofs mountpoint) with garbage. When it
is later mounted you get the real info. Would that work?
You would only mount when someone wants to know what the dir contains
(readdir, any others?). And what happens with the inode that we have
cached from our ls -l, can it be safely updated with the new info?
And the problem is doing this with autofs, cleanly ... I'm going to bed
now, my head is hurting :)
/Urban
