bug#50189: wdired chmod should not follow symlinks

bug#50189: wdired chmod should not follow symlinks

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

To be consistent with dired M, wdired's method of textually editing a 
symlink's permissions should also not follow symlinks. Proposed patch 
attached.

I did not test this, as I don't use wdired and couldn't get it to work 
for me regardless of whether the patch is applied.

This patch also removes some obsolete commentary about dired-chmod-program.

[-- Attachment #2: 0001-Make-wdired-match-dired-with-symlink-permissions.patch --]
[-- Type: text/x-patch, Size: 2071 bytes --]

From 9b31a8ea5a919d67c6e78706b1b86ffbdf336e11 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 24 Aug 2021 11:00:52 -0700
Subject: [PATCH] Make wdired match dired with symlink permissions

* lisp/wdired.el (wdired-do-perm-changes): Do not follow symlinks,
to be consistent with plain dired.
---
 lisp/wdired.el | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/lisp/wdired.el b/lisp/wdired.el
index fd549bac32..70dfd2c80a 100644
--- a/lisp/wdired.el
+++ b/lisp/wdired.el
@@ -45,8 +45,7 @@
 ;;
 ;; - Change the target of symbolic links.
 ;;
-;; - Change the permission bits of the filenames (in systems with a
-;;   working unix-alike `dired-chmod-program').  See and customize the
+;; - Change the permission bits of the filenames.  See and customize the
 ;;   variable `wdired-allow-to-change-permissions'.  To change a single
 ;;   char (toggling between its two more usual values) you can press
 ;;   the space bar over it or left-click the mouse.  To set any char to
@@ -125,10 +124,7 @@ wdired-allow-to-change-permissions
 If `advanced', the bits are freely editable.  You can use
 `string-rectangle', `query-replace', etc.  You can put any value (even
 newlines), but if you want your changes to be useful, you better put a
-intelligible value.
-
-Anyway, the real change of the permissions is done by the external
-program `dired-chmod-program', which must exist."
+intelligible value."
   :type '(choice (const :tag "Not allowed" nil)
                  (const :tag "Toggle/set bits" t)
 		 (other :tag "Bits freely editable" advanced)))
@@ -995,7 +991,8 @@ wdired-do-perm-changes
         (setq filename (wdired-get-filename nil t))
         (if (= (length perms-new) 10)
             (condition-case nil
-                (set-file-modes filename (wdired-perms-to-number perms-new))
+		(set-file-modes filename (wdired-perms-to-number perms-new)
+				'nofollow)
               (error
                (setq errors (1+ errors))
                (dired-log "Setting mode of `%s' to `%s' failed\n\n"
-- 
2.31.1

bug#50189: wdired chmod should not follow symlinks (Bug#11912 followup)

[Lars Ingebrigtsen]

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

> I did not test this, as I don't use wdired and couldn't get it to work
> for me regardless of whether the patch is applied.

Yeah, editing the permissions doesn't seem to work for me in dired.  If
I start with

  -rw-r--r--  1 larsi      larsi       329K Aug 21 18:22 IMG_4478.JPG

and press DEL after the final dash, it'll delete the dash and then say
"Text is read only", leaving me with:

  -rw-r--r-  1 larsi      larsi       329K Aug 21 18:22 IMG_4478.JPG

And then I can't insert anything there, because it's now read-only.  So
something is wonky in the way wdired tries to make certain bits of the
line read-only.

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

bug#50189: wdired chmod should not follow symlinks (Bug#11912 followup)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yeah, editing the permissions doesn't seem to work for me in dired.  If
> I start with
>
>   -rw-r--r--  1 larsi      larsi       329K Aug 21 18:22 IMG_4478.JPG
>
> and press DEL after the final dash, it'll delete the dash and then say
> "Text is read only", leaving me with:
>
>   -rw-r--r-  1 larsi      larsi       329K Aug 21 18:22 IMG_4478.JPG
>
> And then I can't insert anything there, because it's now read-only.  So
> something is wonky in the way wdired tries to make certain bits of the
> line read-only.

Setting wdired-allow-to-change-permissions to t or `advanced' made this
work -- you can't really edit the permissions without that.

So I guess there's nothing more to be done here...

bug#50189: wdired chmod should not follow symlinks (Bug#11912 followup)

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > Yeah, editing the permissions doesn't seem to work for me in dired.  If
> > I start with
> >
> >   -rw-r--r--  1 larsi      larsi       329K Aug 21 18:22 IMG_4478.JPG
> >
> > and press DEL after the final dash, it'll delete the dash and then say
> > "Text is read only", leaving me with:
> >
> >   -rw-r--r-  1 larsi      larsi       329K Aug 21 18:22 IMG_4478.JPG
> >
> > And then I can't insert anything there, because it's now read-only.  So
> > something is wonky in the way wdired tries to make certain bits of the
> > line read-only.
>
> Setting wdired-allow-to-change-permissions to t or `advanced' made this
> work -- you can't really edit the permissions without that.

That behavior not optimal and a bit confusing.

As you might remember, text properties in wdired are now attached on the
fly for better performance, implemented here:

| 4dbc44550d * lisp/wdired.el: Apply text properties lazily
| Arthur Miller <arthur.miller@live.com> 2021-03-27

[Arthur is CC'd]

The problem in this case: the read-only property is attached in
`before-change-functions'.  But that doesn't prevent the change being
performed.  Try e.g. in *scratch*:

#+begin_src emacs-lisp
(add-hook 'before-change-functions
          (lambda (&rest _)
            (put-text-property (point-min) (point-max)
                               'read-only t))
          nil t)
#+end_src

The first changes goes through although the text is already read-only,
because it's still the same command or so (anyone thinking this is a
bug?).

I think we could make wdired explicitly check for and throw a
"user-error" in this case so that the editing command is not performed
(but only after the properties were attached).

TIA,

Michael.

bug#50189: wdired chmod should not follow symlinks (Bug#11912 followup)

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> Setting wdired-allow-to-change-permissions to t or `advanced' made this
>> work -- you can't really edit the permissions without that.
>
> That behavior not optimal and a bit confusing.

Yeah, like a lot of stuff with dired and wdired, unfortunately.

> I think we could make wdired explicitly check for and throw a
> "user-error" in this case so that the editing command is not performed
> (but only after the properties were attached).

You mean in the wdired-allow-to-change-permissions nil case?  Yes,
definitely.

bug#50189: wdired chmod should not follow symlinks (Bug#11912 followup)

[Lars Ingebrigtsen]

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

> To be consistent with dired M, wdired's method of textually editing a
> symlink's permissions should also not follow symlinks. Proposed patch
> attached.

The patch looks "obviously correct", so I've applied it to Emacs 29.