bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

["Michalis V." <mvar.40k@gmail.com>]

Lars Ingebrigtsen <larsi@gnus.org> writes:
> In Linux you can't change the permissions on a symlink (they're always
> 777):
>
>        chmod never changes the permissions of symbolic links; the chmod system
>        call cannot change their permissions.  This is not a problem since  the
>        permissions  of  symbolic links are never used. 
>
> So I'm surprised that the `M' command even tries to do the chmod on the
> symlink.  This was apparently done as part of a security audit:
>
> commit 9d626dffc6ba62c0d7a1a5c712f576ed8684fd66
> Author:     Paul Eggert <eggert@cs.ucla.edu>
> AuthorDate: Sun Feb 23 16:19:42 2020 -0800
>
>     Add 'nofollow' flag to set-file-modes etc.
>     
>     This avoids some race conditions (Bug#39683).  E.g., if some other
>     program changes a file to a symlink between the time Emacs creates
>     the file and the time it changes the file’s permissions, using the
>     new flag prevents Emacs from inadvertently changing the
>     permissions of a victim in some completely unrelated directory.
>
> Hm.  I'm not sure why this should affect the `M' command in dired, though...
>
> I've added Paul to the CCs; perhaps he has some comments.

that's true; but doing chmod on the symlink from bash will actually
have effect on the symlinked file itself, so from a user perspective
i'd expect dired to behave similarly (that is, M to resolve the symlink
and apply the chmod mask to the actual file). But i never thought of
race conditions and potential security problems so the current behavior
looks like the best one.

thanks,
Michalis