bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file

[Eli Zaretskii]

> From: Matt Armstrong <matt@rfc20.org>
> Cc: 46397@debbugs.gnu.org, craven@gmx.net
> Date: Sun, 07 Mar 2021 18:18:46 -0800
> 
> It turns out that naming a directory the same as the would-be lock file
> suffices to induce errors in a portable way.
> 
> I've updated the (substantially simplified) test in patch 0001,
> incorporating Eli's feedback.
> 
> Patch 0002 implements the handling of unlock errors as warnings by way
> of a userlock.el function.  I figure that function would be a handy hook
> for people to use with `debug-on-entry', if they want.
> 
> Both ready for review now.

Thanks, I have just two minor comments:

  . I'd prefer a slightly different warning text, see below
  . We need this change to be reflected in NEWS and perhaps in the manual

> Things I noticed:
> 
>  a) if a buffer becomes unmodified by way of `undo' it is unlocked
>     twice, causing two warnings.
>  b) the file errors generated contain the original file name, not the
>     lock file name.
> 
> I am treating both of of those things as not worth fixing, at least for
> now.

Right, I agree.

> +(defun userlock--handle-unlock-error (err)
> +  "Report an error ERR that occurred while unlocking a file."
> +  (display-warning
> +   '(unlock-file)
> +   (message "Error unlocking file, proceeding as if unlocked: %s"
> +            (error-message-string err))

I think "proceeding as if unlocked" may be slightly confusing,
especially for non-native English speakers.  How about this instead:

  Error unlocking file %s, ignored

Thanks.