Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Eli Zaretskii]

> --- a/lisp/ChangeLog	2014-02-07 07:51:56 +0000
> +++ b/lisp/ChangeLog	2014-02-07 07:58:10 +0000
> @@ -1,5 +1,10 @@
>  2014-02-07  Juri Linkov  <juri@jurta.org>
>  
> +	* desktop.el (desktop-read): Claim the lock when the owner is not
> +	the current process.  (Bug#16157)
> +

What happens if an Emacs session that locked the desktop file is still
alive?

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juri Linkov]

>> +	* desktop.el (desktop-read): Claim the lock when the owner is not
>> +	the current process.  (Bug#16157)
>
> What happens if an Emacs session that locked the desktop file is still
> alive?

The one that comes last wins.  The last session will do auto-saving,
the previous won't.  At least, there should be no conflict of both sessions
trying to auto-save to the same file, because auto-saving checks the ownership.
The conflict might occur when during exiting both sessions will try writing
to the same file.  I see nothing in `desktop-kill' that would prevent saving
to a non-locked desktop, except the question "Save desktop?"

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juanma Barranquero]

On Fri, Feb 7, 2014 at 8:42 PM, Juri Linkov <juri@jurta.org> wrote:

> The one that comes last wins.

Why is that better? I often start a second Emacs instance, and in
almost all cases I want the first one to keep the desktop.

What problem is that trying to fix, and why isn't
desktop-load-locked-desktop enough?

    J

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 07 Feb 2014 21:42:00 +0200
> 
> >> +	* desktop.el (desktop-read): Claim the lock when the owner is not
> >> +	the current process.  (Bug#16157)
> >
> > What happens if an Emacs session that locked the desktop file is still
> > alive?
> 
> The one that comes last wins.  The last session will do auto-saving,
> the previous won't.  At least, there should be no conflict of both sessions
> trying to auto-save to the same file, because auto-saving checks the ownership.
> The conflict might occur when during exiting both sessions will try writing
> to the same file.  I see nothing in `desktop-kill' that would prevent saving
> to a non-locked desktop, except the question "Save desktop?"

That's not what I see today, I think.  When I need to test something
in a fresh session, I sometimes by mistake invoke "emacs" instead of
"emacs -Q", which reads my ~/.emacs and activates desktop saving.  The
main Emacs session is alive, of course.  Then, when I exit, I'm asked
whether to save desktop and given the opportunity to say NO, because I
certainly don't want my main desktop file to be overwritten by this
mistaken session.  I'm not sure this change doesn't eliminate this
useful capability.

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juri Linkov]

>> The one that comes last wins.
>
> Why is that better? I often start a second Emacs instance, and in
> almost all cases I want the first one to keep the desktop.
>
> What problem is that trying to fix, and why isn't
> desktop-load-locked-desktop enough?

The problem was that when a session crashes, all subsequent sessions
can't auto-save the desktop since they didn't take the lock
from the crashed session.

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juri Linkov]

>> The one that comes last wins.  The last session will do auto-saving,
>> the previous won't.  At least, there should be no conflict of both sessions
>> trying to auto-save to the same file, because auto-saving checks the ownership.
>> The conflict might occur when during exiting both sessions will try writing
>> to the same file.  I see nothing in `desktop-kill' that would prevent saving
>> to a non-locked desktop, except the question "Save desktop?"
>
> That's not what I see today, I think.  When I need to test something
> in a fresh session, I sometimes by mistake invoke "emacs" instead of
> "emacs -Q", which reads my ~/.emacs and activates desktop saving.  The
> main Emacs session is alive, of course.  Then, when I exit, I'm asked
> whether to save desktop and given the opportunity to say NO,

When you invoke "emacs" instead of "emacs -Q" by mistake,
it warns you about the mistake by asking

  "Warning: desktop file appears to be in use by PID %s.
   Using it may cause conflicts.  Use it anyway? "

so you could just say NO.

> because I certainly don't want my main desktop file to be overwritten
> by this mistaken session.  I'm not sure this change doesn't eliminate
> this useful capability.

Even when you answer YES, and a new session will auto-save the desktop,
you still can save the final version of the desktop from the first session
if you exit it later than the auto-saving session, so it will overwrite
the desktop from the latest exited session.

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juanma Barranquero]

On Sat, Feb 8, 2014 at 11:11 AM, Juri Linkov <juri@jurta.org> wrote:

> The problem was that when a session crashes, all subsequent sessions
> can't auto-save the desktop since they didn't take the lock
> from the crashed session.

Surely I'm missing something, but what good is the lock if subsequent
sessions can steal it even if the corresponding Emacs is still
running?

   J

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juri Linkov]

>> The problem was that when a session crashes, all subsequent sessions
>> can't auto-save the desktop since they didn't take the lock
>> from the crashed session.
>
> Surely I'm missing something, but what good is the lock if subsequent
> sessions can steal it even if the corresponding Emacs is still
> running?

Maybe we need a separate question in addition to the existing question

1. "Warning: desktop file appears to be in use by PID %s.
    Using it may cause conflicts.  Use it anyway? "

something like

2. "Claim the lock from PID %s to take the ownership of the desktop file? "

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juanma Barranquero]

On Sat, Feb 8, 2014 at 11:35 AM, Juri Linkov <juri@jurta.org> wrote:

> Maybe we need a separate question in addition to the existing question
>
> 1. "Warning: desktop file appears to be in use by PID %s.
>     Using it may cause conflicts.  Use it anyway? "
>
> something like
>
> 2. "Claim the lock from PID %s to take the ownership of the desktop file? "

Something like that, but it needs to be possible to configure it to
not ask/not claim, if that's what the user wants.

As an example, in my .emacs, I set desktop-load-locked-desktop to nil,
and then I add code to desktop-not-loaded-hook that only steals the
lock if the PID of the old lock does not match a running Emacs
instance; if the old Emacs is still running I only throw a warning.

   J

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> The one that comes last wins.  The last session will do auto-saving,
>>> the previous won't.  At least, there should be no conflict of both sessions
>>> trying to auto-save to the same file, because auto-saving checks the ownership.
>>> The conflict might occur when during exiting both sessions will try writing
>>> to the same file.  I see nothing in `desktop-kill' that would prevent saving
>>> to a non-locked desktop, except the question "Save desktop?"
>>
>> That's not what I see today, I think.  When I need to test something
>> in a fresh session, I sometimes by mistake invoke "emacs" instead of
>> "emacs -Q", which reads my ~/.emacs and activates desktop saving.  The
>> main Emacs session is alive, of course.  Then, when I exit, I'm asked
>> whether to save desktop and given the opportunity to say NO,
>
> When you invoke "emacs" instead of "emacs -Q" by mistake,
> it warns you about the mistake by asking
>
>   "Warning: desktop file appears to be in use by PID %s.
>    Using it may cause conflicts.  Use it anyway? "
>
> so you could just say NO.

It will still want to _save_ the desktop even if you answer No to
loading it.

-- 
David Kastrup

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 08 Feb 2014 12:14:44 +0200
> 
> >> The one that comes last wins.  The last session will do auto-saving,
> >> the previous won't.  At least, there should be no conflict of both sessions
> >> trying to auto-save to the same file, because auto-saving checks the ownership.
> >> The conflict might occur when during exiting both sessions will try writing
> >> to the same file.  I see nothing in `desktop-kill' that would prevent saving
> >> to a non-locked desktop, except the question "Save desktop?"
> >
> > That's not what I see today, I think.  When I need to test something
> > in a fresh session, I sometimes by mistake invoke "emacs" instead of
> > "emacs -Q", which reads my ~/.emacs and activates desktop saving.  The
> > main Emacs session is alive, of course.  Then, when I exit, I'm asked
> > whether to save desktop and given the opportunity to say NO,
> 
> When you invoke "emacs" instead of "emacs -Q" by mistake,
> it warns you about the mistake by asking
> 
>   "Warning: desktop file appears to be in use by PID %s.
>    Using it may cause conflicts.  Use it anyway? "

Not if I load from a different desktop file.

> > because I certainly don't want my main desktop file to be overwritten
> > by this mistaken session.  I'm not sure this change doesn't eliminate
> > this useful capability.
> 
> Even when you answer YES, and a new session will auto-save the desktop,
> you still can save the final version of the desktop from the first session
> if you exit it later than the auto-saving session, so it will overwrite
> the desktop from the latest exited session.

Isn't it safer to see of the PID that locked the desktop file still
runs, and if so, ask for permission?

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Isn't it safer to see of the PID that locked the desktop file still
> runs, and if so, ask for permission?

What if the other instance runs on a different host?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Juri Linkov <juri@jurta.org>,  emacs-devel@gnu.org
> Date: Sat, 08 Feb 2014 12:16:15 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Isn't it safer to see of the PID that locked the desktop file still
> > runs, and if so, ask for permission?
> 
> What if the other instance runs on a different host?

What if the PID is reused?

Yes, we could cater to all these, if we want.  But not using even the
PID seems too sloppy, IMO.

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juri Linkov]

>> Maybe we need a separate question in addition to the existing question
>>
>> 1. "Warning: desktop file appears to be in use by PID %s.
>>     Using it may cause conflicts.  Use it anyway? "
>>
>> something like
>>
>> 2. "Claim the lock from PID %s to take the ownership of the desktop file? "
>
> Something like that, but it needs to be possible to configure it to
> not ask/not claim, if that's what the user wants.

Then instead of asking a question we could add two new values
to `desktop-load-locked-desktop'

   ask-and-lock  -- ask the user and lock the desktop.
   load-and-lock -- load and lock anyway.

with the default to `ask-and-lock'.  Whereas the existing

   t    -- load anyway.
   ask  -- ask the user.

will load without locking.

> As an example, in my .emacs, I set desktop-load-locked-desktop to nil,
> and then I add code to desktop-not-loaded-hook that only steals the
> lock if the PID of the old lock does not match a running Emacs
> instance; if the old Emacs is still running I only throw a warning.

I guess your code to detect a running Emacs instance is not too reliable
to include to desktop.el?

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juanma Barranquero]

On Sat, Feb 8, 2014 at 8:32 PM, Juri Linkov <juri@jurta.org> wrote:

> Then instead of asking a question we could add two new values
> to `desktop-load-locked-desktop'
>
>    ask-and-lock  -- ask the user and lock the desktop.
>    load-and-lock -- load and lock anyway.
>
> with the default to `ask-and-lock'.  Whereas the existing
>
>    t    -- load anyway.
>    ask  -- ask the user.
>
> will load without locking.

Seems OK.

> I guess your code to detect a running Emacs instance is not too reliable
> to include to desktop.el?

Alas, no. It's Windows-specific, and depends on the fact that I know I
won't have a lock from a remote Emacs instance, and that all my
instances are launched from executables called emacs.exe.

    J

Re: [Emacs-diffs] trunk r116304: * lisp/desktop.el (desktop-read): Claim the lock when the owner is not the current process.

[Juanma Barranquero]

On Sat, Feb 8, 2014 at 9:29 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

> Alas, no. It's Windows-specific, and depends on the fact that I know I
> won't have a lock from a remote Emacs instance, and that all my
> instances are launched from executables called emacs.exe.

Well, not really Windows-specific, though it does depend on the other
two conditions. Basically I'm doing something like this:

(setq desktop-load-locked-desktop nil)
(add-hook 'desktop-not-loaded-hook
          (lambda ()
            (let ((owner (desktop-owner))
                  (desktop-load-locked-desktop t))
              (cond ((= owner (emacs-pid))
                     (desktop-read))
                    ((let ((command (cdr (assq 'comm
(process-attributes owner))))
                           (case-fold-search t))
                       (and command
                            (string-match-p
"^emacs\\(?:-[0-9.]+\\)?\\(?:\\.exe\\)$" command)))
                     (warn "Locked by Emacs (%s)" owner)
                     (desktop-save-mode -1))
                    ((ignore-errors (delete-file (desktop-full-lock-name)) t)
                     (warn "Stale lock by Emacs (%s) deleted" owner)
                     (desktop-read))
                    (t
                     (warn "Could not delete stale lock by Emacs (%s)" owner)
                     (desktop-save-mode -1))))))