On Sat, 2020-02-01 at 22:39 +0100, Marc Lehmann wrote:
> On Sat, Feb 01, 2020 at 07:41:03AM +0800, Ian Kent <ik...@redhat.com>
> wrote:
> > > decided that nobody should use symlinks as bind mounts are the
> > > future(tm).
> > > From an upstream POV it was more neglect (on my part) of the
> > symlink code in favour of bind mounts.
> 
> Not sure why you write this, but it's clearly not true:
> 
>    Date: Tue, 29 May 2001 14:00:42 -0700
>    [...]
>    I don't want to perpetuate the symlink thing because it is a
> terrible
>    hack in the kernel part of the code, and thus will be removed in
> autofs
>    v5.
> 
>            -hpa
> 
> (I hope he forgives me to quote a private mail, but the fact is
> documented
> in debian bug #128171).
> 
> That was probably a bit before your time, but the last time I
> reported
> problems with symlinks to upstream I was told (in a long thread) that
> it
> is a hack and will not be supported.

Yes, it was before my time and things have changed a lot.

TBH I'm not sure what hpa was referring to there.

He may have been talking about the abuse of symlink following
in the VFS to effect automounting, but that's long since been
resolved by adding automount support to the VFS itself, not
only for use by autofs but other file systems like NFS, CIFS,
AFS, etc..

> 
> And the result was that the debian maintainer locally applied a patch
> (in
> 2006) to make symlinks configurable, for which I was super-thankful.
> 
> (Note that there are two sides to this: symlinks for local nfs
> mounts, and
> symlinks for bind mounts, which are not the same, and which confused
> me for
> quite a while).
> 
> > But the autofs amd format map support needs them to work properly
> > so quite a bit of effort went into making them work as best as I
> > could.
> 
> Yes, I am very fond of this change in policy, thanks a lot - the
> effect is
> that I can consider autofs again for new deployments, rather than
> having
> had to give up on it :) I also am very fond of amd map support,
> although
> documentation, of course, is sorely lacking.

Yeah, but the amd support is very much for people that can't
convert their maps to autofs format to get the same function.

You can always look to:
https://www.am-utils.org/docs/am-utils/am-utils.pdf

while it's still around.

Then it's just a matter of working out what's not supported
in autofs and that's not all that much.

The main problem with using autofs with amd maps is the way
autofs works internally, it's different to amd so you end up
with more actual mounts which isn't ideal from an amd POV.

> 
> In any case, since we all seems to agree on the bug part, I think
> this
> part of the disucssion (who stated what policy when) should stay off
> the
> debian bts :)

Agreed, the autofs mailing list is the better place for these
discussions, ;)

Ian

Reply via email to