bug#34338: 26.1; delete-file return codes and failures

[Boruch Baum]

On 2019-02-06 18:19, Eli Zaretskii wrote:
> > Date: Tue, 5 Feb 2019 16:47:37 -0500
> > From: Boruch Baum <boruch_baum@gmx.com>
>
> As Michael points out, there's one optional argument already, and we
> need to preserve it.

Yup.

>
> > B2) raise an error when (not NOERROR) and:
> >
> >   B2.1) file doesn't exist
> >
> >   B2.2) (and (chmod -w) (not FORCE))
> >
> >   B2.3) another form of permission denial is encountered
>
> !ERROR and either of the following, or all of them?

Either.

> In any case, you propose a backward-incompatible change in behavior,
> so it won't fly. We could perhaps do it the other way around: add a
> new optional argument ERROR-OUT, which, when non-nil, will cause the
> function to signal an error when B2.1 or B2.2 happen (I believe B2.3
> already causes an error). And similarly with FORCE.

> IOW
> ... (snip) ...

The part that would transform a prior condition of 'crash' to some
return value is a kind of backward-incompatibility that I think most
people would appreciate. The issue would be if there exists code in
emacs that traps on the current crashes (eg. using 'condition-case'). I
like the idea of requiring non-nil to force an ERROR-OUT, but that would
inconsistent with the more common emacs use of NOERROR as an arg.

For a proposed FORCE arg, backward-incompatibility is a positive
feature, a bug-fix, in that emacs is not currently respecting a user's
environment choice to place a level of protection from deleting the
target file. A user made a conscious positive act at some point to
put a level of protection on a file, that in the usual context, 'rm',
would require further interaction in order to proceed, and emacs is
currently not abiding by that.

> > C) maybe log the exact error or reason for nil to *Messages*.
>
> Not sure what you mean by "exact error or reason", I believe we
> already log the reason.

For me, in response chmod -x $parent_dir, the error message is:

  eval: Removing old name: Permission denied, /home/boruch/foo/bar

And the response to chattr +i bar

  eval: Removing old name: Operation not permitted, /home/boruch/foo/bar

So the messages are unique, but not clear.

> Finally, did you think how to allow users set or reset these new knobs
> when invoking delete-file interactively?

No! Um ....

> I think these options are mainly for interactive use, and in that case
> we should have some convenient way of setting them interactively.

So, currently the prefix arg is already being used for TRASH ...

Interactively, having a 'knob' for NOERROR (or its reverse, per above)
doesn't seem to me necessary ... what value does it add for an
interactive invocation? ...

Interactively, for FORCE, there's no 'lossage-advantage' (borrowed term
based upon `C-h l') to requiring a user to add keystrokes up-front prior
to delete-file, rather than requiring the user to y-or-n if the file has
protection. So, that doesn't seem necessary, unless you want to add a
feature to allow delete-file to operate on a regex or sequence of
filenames instead of a single file.

That leaves my off-topic comment to Michael about a THRASH (not TRASH,
but maybe better SHRED) arg. My input on that would be to have such a
feature as a separate function (eg. shred-file), and not an arg to
delete-file.

חודש טוב ואדר כפול שמח.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0