GNU bug report logs - #11912
24.1; 'M' in Dired on a symlink does not refresh the display

Previous Next

To reply to this bug, email your comments to 11912 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1; 'M' in Dired on a symlink does not refresh the display
Date: Wed, 11 Jul 2012 19:30:39 +0300

On a system that supports symlinks, do this:

 emacs -Q
 C-x d RET

Go to any file and type

 S foobar RET

This creates a symlink named 'foobar' to the file on whose line you
were when you typed S.  Now go to the line of 'foobar' and type this:

 M 0444 RET

Emacs says "Redisplaying...done", but the mode bits of the target of
the symlink do not reflect the change.  Type 'g', and they will.

From a cursory look at the code (dired-do-redisplay), it sounds like
Dired assumes that the file to be refreshed is necessarily on the
current line (or marked).  This is false for symlinks and the 'M'
command (and probably a few others, like 'O'), because the file that
changes is the target of the symlink.

I think this bug was in Emacs since about forever; I tried as far back
as Emacs 22.1, and the problem was still there.


In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-11 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  diff-auto-refine-mode: t
  flyspell-mode: t
  desktop-save-mode: t
  show-paren-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent input:
n SPC t h e SPC n e t . <return> <right> <up> <C-left> 
<C-left> <C-right> SPC W i n d o w s M-q <down> <down> 
<up> <up> <up> <C-left> <C-left> <C-left> <C-left> 
l i b f f i SPC M-q <down> <down> <down> <C-home> C-c 
C-s <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <switch-frame> d <next> <next> <next> <prior> 
<next> <next> <next> <prior> <C-home> <C-end> <prior> 
<prior> <prior> <prior> <prior> d d <next> d d <next> 
d d d d d d <next> d d <next> d d d d d d d d d d d 
d <next> d <next> <next> d <next> d d d d d d d d d 
d d d SPC o <up> <up> <down> <return> d d d d d SPC 
d d C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z <next> 
<next> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
<prior> SPC SPC SPC SPC SPC SPC SPC SPC SPC <prior> 
<prior> <prior> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <prior> <prior> <prior> <prior> 
<prior> C-r e g g e <M-left> <next> d d d d d SPC d 
SPC d d d d d SPC d d d d d n d SPC d d d d d d d d 
d n d d d d d d d d SPC d d d d <down> n SPC d d d 
d d d d d d d d d d d d d SPC d d SPC d SPC d d SPC 
d SPC d d d d d d d d C-z C-z C-z C-z C-z C-z C-z C-z 
C-z C-z d C-x C-s <switch-frame> M-x r e p o r t <tab> 
<return>

Recent messages:
Sending email done
Sending...done
Mark set [2 times]
Showing message 3132
Showing message 3132...done
Added to d:/usr/eli/rmail/TEXINFO.rmail
Mark saved where search started
No following nondeleted message
Saving file d:/usr/eli/rmail/INBOX...
Wrote d:/usr/eli/rmail/INBOX [2 times]

Load-path shadows:
None found.

Features:
(shadow emacsbug multi-isearch network-stream starttls tls smtpmail
auth-source eieio assoc gnus-util password-cache mailalias sendmail
rmailout tcl nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml
rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt
rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap nxml-util
nxml-glyph nxml-enc xmltok sgml-mode conf-mode newcomment parse-time
generic ld-script sh-script executable vc-git arc-mode archive-mode
diff-mode dired-x dired make-mode tar-mode vc-cvs face-remap org-wl
org-w3m org-vm org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs
org-html org-exp ob-exp org-exp-blocks find-func org-agenda org-info
org-gnus org-docview org-bibtex bibtex org-bbdb org byte-opt warnings
bytecomp byte-compile cconv macroexp advice help-fns advice-preload
ob-emacs-lisp ob-tangle ob-ref ob-lob ob-table org-footnote org-src
ob-comint ob-keys ob ob-eval org-pcomplete pcomplete comint ansi-color
ring org-list org-faces org-compat org-entities org-macs noutline
outline easy-mmode cal-menu calendar cal-loaddefs flyspell texinfo
jka-compr autorevert info vc-bzr cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt qp
rmailsum rmailmm message format-spec rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231
rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils desktop
server filecache mairix cus-edit easymenu cus-start cus-load wid-edit
saveplace midnight ispell generic-x paren battery time time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table
ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty
emacs)

Message #10 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: "Michalis V." <mvar.40k <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11912 <at> debbugs.gnu.org
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Tue, 24 Aug 2021 13:23:37 +0300

Eli Zaretskii <eliz <at> gnu.org> writes:

> On a system that supports symlinks, do this:
>
>  emacs -Q
>  C-x d RET
>
> Go to any file and type
>
>  S foobar RET
>
> This creates a symlink named 'foobar' to the file on whose line you
> were when you typed S.  Now go to the line of 'foobar' and type this:
>
>  M 0444 RET
>
> Emacs says "Redisplaying...done", but the mode bits of the target of
> the symlink do not reflect the change.  Type 'g', and they will.
>
>>From a cursory look at the code (dired-do-redisplay), it sounds like
> Dired assumes that the file to be refreshed is necessarily on the
> current line (or marked).  This is false for symlinks and the 'M'
> command (and probably a few others, like 'O'), because the file that
> changes is the target of the symlink.
>
> I think this bug was in Emacs since about forever; I tried as far back
> as Emacs 22.1, and the problem was still there.


hi,

I can reproduce this in 27.1 but in 28.0.50 i get the following message:

Doing chmod: Operation not supported, /tmp/foobar

chmod on the symlinked file itself works ("Redisplaying..." too)

perhaps this functionality was disabled/removed for symlinks on purpose?
or is it a new bug?


Michalis

Message #13 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Michalis V." <mvar.40k <at> gmail.com>
Cc: 11912 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Tue, 24 Aug 2021 17:40:28 +0200

"Michalis V." <mvar.40k <at> gmail.com> writes:

> I can reproduce this in 27.1 but in 28.0.50 i get the following message:
>
> Doing chmod: Operation not supported, /tmp/foobar
>
> chmod on the symlinked file itself works ("Redisplaying..." too)
>
> perhaps this functionality was disabled/removed for symlinks on purpose?
> or is it a new bug?

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 <at> 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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #16 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Michalis V." <mvar.40k <at> gmail.com>, 11912 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Tue, 24 Aug 2021 10:32:01 -0700

[Message part 1 (text/plain, inline)]

On 8/24/21 8:40 AM, Lars Ingebrigtsen wrote:

> I'm surprised that the `M' command even tries to do the chmod on the
> symlink.

Unfortunately the M command doesn't know in advance whether chmod will 
work on the symlink, as that is platform and filesystem dependent (this 
is in addition to the usual race-condition problem). So as a practical 
matter the M command must try the chmod and report the failure somehow. 
(Perhaps the reporting could be improved; I expect that's low priority.)

A few things:

* I neglected to document this behavior change, so I just now installed 
the attached to fix that oversight.

* Because of this behavior change, the example Eli gives at the start of 
Bug#11912 is now obsolete, as the bug has been fixed in a different way. 
However, as Eli mentioned, there are other commands (like 'O') where the 
bug is still present.

* And this suggests that some longstanding security and other bugs 
remain in this area. I plan to file more bug reports that will cite 
Bug#11912. If the other bugs are fixed, then Bug#11912 should be 
completely obsolete and can be closed.

[0001-Doc-that-dired-do-chmod-no-longer-follows-symlinks.patch (text/x-patch, attachment)]

Message #19 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: "Michalis V." <mvar.40k <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Michalis V." <mvar.40k <at> gmail.com>, 11912 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Wed, 25 Aug 2021 11:37:34 +0300

Lars Ingebrigtsen <larsi <at> 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 <at> 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

Message #22 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "Michalis V." <mvar.40k <at> gmail.com>, 11912 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Wed, 25 Aug 2021 12:57:56 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> * I neglected to document this behavior change, so I just now
>   installed the attached to fix that oversight.

I understand the security-related reasons for changing the `M' command,
but I'm wondering whether they are weighty enough to make it more
inconvenient for the user to use symlinks in Emacs.

The reasoning is that an attacker may control a symlink and make it
point to somewhere else.  So I may have 

  lrwxrwxrwx  1 evil      evil         17 Aug 25 12:52 foosym -> /tmp/IMG_4475.JPG

in my dired buffer, and then "evil" changes the link to point to
somewhere else, and then I say `M' on the link, and then I operated on
the wrong file.

However, on the command line, chmod is fine with following symlinks, so
the user can just `! chmod 0444' instead, and the same will happen.

So is inconveniencing people who are using the `M' command worth it?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #25 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Michalis V." <mvar.40k <at> gmail.com>, 11912 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Wed, 25 Aug 2021 10:59:23 -0700

On 8/25/21 3:57 AM, Lars Ingebrigtsen wrote:
> on the command line, chmod is fine with following symlinks

Yes, that's what POSIX requires. However, Dired is different from the 
POSIX shell, because a Dired user sees the permissions on a symbolic 
link while typing the command to the edit permissions, and the natural 
assumption is that one is editing what one is seeing. This is even more 
true of Wdired (Bug#50189); and it's also quite true for Dired.

That is why G, O, T should also be fixed (see Bug#50191). The Dired 
users sees the group, ownership, and timestamp of the symlink while 
typing the "change the group" (or whatever) command, so the natural 
assumption is that one is changing what one is seeing.

This assumption is so hardwired that it is the original motivation for 
the coding error that prompted Bug#11912.

Message #28 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: mvar.40k <at> gmail.com, 11912 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#11912: 24.1;
 'M' in Dired on a symlink does not refresh the display
Date: Wed, 25 Aug 2021 23:57:59 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I understand the security-related reasons for changing the `M' command,
  > but I'm wondering whether they are weighty enough to make it more
  > inconvenient for the user to use symlinks in Emacs.

It's not just for the sake of security.  Dired commands generally
operate on the files you see in the Dired buffer.  If what you see in
the dired buffer is a symlink, it is still surprising for a Dired command
to alter the file that the symlink points to.

I wouldn't assume that a user who uses M on a symlink in Dired wants
to alter the file it points to.  I think it is more likely that the
user did not realize it might do that.  Suppose you operate on 10
files and one is a symlink -- you might not even have noticed that one
is as symlink.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #31 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "Michalis V." <mvar.40k <at> gmail.com>, 11912 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Thu, 26 Aug 2021 15:52:34 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> Yes, that's what POSIX requires. However, Dired is different from the
> POSIX shell, because a Dired user sees the permissions on a symbolic
> link while typing the command to the edit permissions, and the natural
> assumption is that one is editing what one is seeing. This is even
> more true of Wdired (Bug#50189); and it's also quite true for Dired.

Yeah, that's a good point.

> That is why G, O, T should also be fixed (see Bug#50191). The Dired
> users sees the group, ownership, and timestamp of the symlink while
> typing the "change the group" (or whatever) command, so the natural
> assumption is that one is changing what one is seeing.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #34 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Richard Stallman <rms <at> gnu.org>
Cc: mvar.40k <at> gmail.com, 11912 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Thu, 26 Aug 2021 15:54:36 +0200

Richard Stallman <rms <at> gnu.org> writes:

> I wouldn't assume that a user who uses M on a symlink in Dired wants
> to alter the file it points to.  I think it is more likely that the
> user did not realize it might do that.  Suppose you operate on 10
> files and one is a symlink -- you might not even have noticed that one
> is as symlink.

Yes, that's a good point.  It's always ambiguous what the user really
wants to do when doing operations on symlinks, and making Dired always
"edit what's actually in the buffer" (i.e., the symlink itself) makes it
less ambiguous (even if it might surprise people who expected Posix
semantics).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #37 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: mvar.40k <at> gmail.com, 11912 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu,
 Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Thu, 26 Aug 2021 16:07:18 +0200

On Aug 26 2021, Lars Ingebrigtsen wrote:

> Richard Stallman <rms <at> gnu.org> writes:
>
>> I wouldn't assume that a user who uses M on a symlink in Dired wants
>> to alter the file it points to.  I think it is more likely that the
>> user did not realize it might do that.  Suppose you operate on 10
>> files and one is a symlink -- you might not even have noticed that one
>> is as symlink.
>
> Yes, that's a good point.  It's always ambiguous what the user really
> wants to do when doing operations on symlinks, and making Dired always
> "edit what's actually in the buffer" (i.e., the symlink itself) makes it
> less ambiguous (even if it might surprise people who expected Posix
> semantics).

But if the dired buffer was created with ls -L, shouldn't M follow
links?

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #40 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: mvar.40k <at> gmail.com, 11912 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the
 display
Date: Thu, 26 Aug 2021 09:52:38 -0700

On 8/26/21 7:07 AM, Andreas Schwab wrote:
> But if the dired buffer was created with ls -L, shouldn't M follow
> links?

Yes, in that case I suppose M should do so (and similarly for G, O, T).

This raises the issue of what to do with output like the following from 
GNU 'ls' when 'c' is a dangling symlink:

  $ ls -lL
  ls: cannot access 'c': No such file or directory
  total 0
  -rw-rw-r-- 1 eggert eggert 0 Aug 26 09:46 b
  l????????? ? ?      ?      ?            ? c


However, these are rare cases; typically dired buffers are created 
without -L and we need to handle the typical cases better.

Message #43 received at 11912 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: mvar.40k <at> gmail.com, 11912 <at> debbugs.gnu.org, larsi <at> gnus.org,
 eggert <at> cs.ucla.edu
Subject: Re: bug#11912: 24.1;
 'M' in Dired on a symlink does not refresh the display
Date: Thu, 26 Aug 2021 23:30:05 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But if the dired buffer was created with ls -L, shouldn't M follow
  > links?

My first thought is that that is right.  But I am not confident of that
conclusion.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.