GNU bug report logs - #50189
wdired chmod should not follow symlinks (Bug#11912 followup)

Previous Next

Full log

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 50189 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Arthur Miller <arthur.miller <at> live.com>
Subject: Re: bug#50189: wdired chmod should not follow symlinks (Bug#11912
 followup)
Date: Sun, 11 Sep 2022 03:32:42 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

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

Previous Next

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