Subject: bug#1474: 23.0.60; desktop.el don't check if pid in his lock file is always in use

From: Eli Zaretskii <[email-masked]>
Date: Sat, 08 Feb 2020 17:20:00 +0200

> From: Stefan Kangas <[email-masked]>
> Date: Sat, 08 Feb 2020 15:23:21 +0100
> Cc: [email-masked], [email-masked]
> 
> Stefan Kangas <[email-masked]> writes:
> 
> > I agree with the proposal, and have written up a suggested patch.
> 
> No comments within 2 weeks.  If no one objects within a couple of
> days, I intend to install this change on master (and consequently
> close this bug).  Please voice any outstanding concerns before that.

Sorry, I failed to present my comments at the time, so let me do that
now:

> +   t      -- load anyway.
> +   nil    -- don't load.
> +   ask    -- ask the user.
> +   check  -- load if locking Emacs process is missing locally.

I'd prefer 'check-pid' or maybe 'dead-pid' for this option.  "Check"
is too general.

> +If the value is `check', load the desktop if the Emacs process
> +that has locked it is not running on the local machine.  This
> +should not be used in circumstances where the locking Emacs might
> +still be running on another machine.  That could be the case if
> +you have remotely mounted (NFS) paths in `desktop-dirname'."

You are right in mentioning that this should not be used for processes
that run on other machines, but how can a user make sure this is not
the case?  Maybe we should modify the contents of the lock file to
include the host where the process was running, like we do with
file-locks?  Or maybe we should still ask for permission if there's no
such process, just with a different text, so that users who are sure
they _never_ run Emacs from another system could decide to unlock the
file more easily?

> +(defun desktop--emacs-pid-running-p (pid)
> +  "Return t if an Emacs process with PID exists."
> +  (when-let ((attr (process-attributes pid)))
> +    (string-match "^emacs$" (alist-get 'comm attr))))

I understand the rationale for the string-match test, but what if the
executable file name of Emacs was "transformed", per the
'--program-transform-name' option of the configure script?  And even
if it wasn't transformed, this will not match emacs-XX.YY and
emacs.exe.

Thanks.