Re: autofsv5 enhancement - map names in /proc/mounts

["Gordon Lack" <gml4410@ggr.co.uk>]

Ian Kent wrote:
>>     Given that there can only be one map active at a mountpoint, and the 
>> first one wins (which is why the -null map works) that would be 
>> /etc/auto.server1.home,
> 
> Ya but for some reason I believed that I was able to do this with the
> Solaris automounter and so v5 now will merge each map.

    Just tried it on Solaris8:

Added these to /etc/auto_master:

  /local/AM /etc/auto.AM1
  /local/AM /etc/auto.AM2

/etc/mntab now has *just* this 1 line at the end:

  /etc/auto.AM1   /local/AM       autofs  indirect,..........

and only the entries in /etc/auto.AM1 work.

This is what I would expect.  eg: -null is there so that you can 
"remove" an entry from an included NIS  auto.master (or equiv).  If the 
code is merging then this won't work, and its supposed to.

It's also perfectly reasonable to have, say, a standard auto.master map, 
and a smaller auto.master.wizards map, with maps in it which are meant 
to *override* the standard ones.

I can't see any benefit in merging things here - only confusing 
complexity.  On Solaris and Irix (and Linux up to autofsv4) I've only 
ever seen the first map mentioned be used (OSF1 uses the last, which is 
truly bizarre, as it creates mountpoints then has to immediately rip 
them out in order to replace them...)

> An individual file name can be up to 255 characters alone.
> They don't have to have spaces to be long.

    Agreed - but is there a limit to the line lengths or total size of 
/proc/mounts?

> How do you use this feature?

    I have a script which reads it and prints the actual mounts that 
exists at a given automount point.  It means I don't need to find out 
which map is handling a particular automount point, nor do I have to 
type in the map name, and I get the keys sorted for me.