Problem with desktop.el

Problem with desktop.el

[David Kastrup]

Hi,

I recently had a desktop restore fail, and the reason was that instead
of the version number 206, in a lot of places instead the character
\316 had been placed.

>From scanning over the source, it would seem that this happens when
desktop restoration is not complete when one saves the desktop again.

What I imagine happened is that I accidentally started Emacs, then
pressed the "Close Window" button on the Emacs frame before loading
the desktop completed, and that Emacs then saved the incompletely
loaded desktop including inserting the version number with "insert"
while it was set to a number.

It might have happened at a read-input call asking for a "y or n"
confirmation about whether it was safe to load a particular buffer's
local variable section.

There are two problems here, I think.  One is that a desktop was saved
while loading it was still in progress.  The other is that the setting
of the desktop-file-version variable is sometimes an integer,
sometimes a string.  Maybe the latter is not a problem if desktop
saving does not happen while the load is still in progress.  But the
resulting unreadable desktop.el does not seem like a reasonable
effect.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Problem with desktop.el

[Richard Stallman]

    There are two problems here, I think.  One is that a desktop was saved
    while loading it was still in progress.

It should be easy to prevent with an explicit test: don't save the
desktop when in the middle of reading one.  Could you write the code
to do that?

Re: Problem with desktop.el

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

Richard Stallman <rms@gnu.org> writes:

>     There are two problems here, I think.  One is that a desktop was saved
>     while loading it was still in progress.
>
> It should be easy to prevent with an explicit test: don't save the
> desktop when in the middle of reading one.  Could you write the code
> to do that?

I think maybe the following would do the trick:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 755 bytes --]

*** desktop.el	25 Jun 2006 14:24:14 +0200	1.102
--- desktop.el	08 Sep 2006 17:36:48 +0200	
***************
*** 862,868 ****
        ;; Desktop file found, process it.
        (let ((desktop-first-buffer nil)
              (desktop-buffer-ok-count 0)
!             (desktop-buffer-fail-count 0))
          (setq desktop-lazy-timer nil)
          ;; Evaluate desktop buffer.
          (load (desktop-full-file-name) t t t)
--- 862,869 ----
        ;; Desktop file found, process it.
        (let ((desktop-first-buffer nil)
              (desktop-buffer-ok-count 0)
!             (desktop-buffer-fail-count 0)
! 	    desktop-save)
          (setq desktop-lazy-timer nil)
          ;; Evaluate desktop buffer.
          (load (desktop-full-file-name) t t t)

[-- Attachment #3: Type: text/plain, Size: 52 bytes --]



-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Problem with desktop.el

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     There are two problems here, I think.  One is that a desktop was saved
>>     while loading it was still in progress.
>>
>> It should be easy to prevent with an explicit test: don't save the
>> desktop when in the middle of reading one.  Could you write the code
>> to do that?
>
> I think maybe the following would do the trick:

I have added another change, since it looks like otherwise we might
get a timer leak.

I am checking in the following change then, all in all:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 893 bytes --]

*** desktop.el	25 Jun 2006 14:24:14 +0200	1.102
--- desktop.el	08 Sep 2006 21:36:39 +0200	
***************
*** 862,869 ****
        ;; Desktop file found, process it.
        (let ((desktop-first-buffer nil)
              (desktop-buffer-ok-count 0)
!             (desktop-buffer-fail-count 0))
!         (setq desktop-lazy-timer nil)
          ;; Evaluate desktop buffer.
          (load (desktop-full-file-name) t t t)
          ;; `desktop-create-buffer' puts buffers at end of the buffer list.
--- 862,870 ----
        ;; Desktop file found, process it.
        (let ((desktop-first-buffer nil)
              (desktop-buffer-ok-count 0)
!             (desktop-buffer-fail-count 0)
! 	    desktop-save)
! 	(desktop-lazy-abort)
          ;; Evaluate desktop buffer.
          (load (desktop-full-file-name) t t t)
          ;; `desktop-create-buffer' puts buffers at end of the buffer list.

[-- Attachment #3: Type: text/plain, Size: 51 bytes --]


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Problem with desktop.el

[Richard Stallman]

Your patch looks plausible; can you test it?

Re: Problem with desktop.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Your patch looks plausible; can you test it?

Well, I checked that the saving of the desktop upon killing Emacs will
no longer trash the desktop file if there is a desktop load in
progress.  That works.

With regard to the lazy timer: I am afraid that this is a complicated
race condition for getting several timers active, and I don't use
them, anyway.  Just setting the timer variable to zero without
stopping the timer can't be a good idea, however, so I think this
change is correct.

I think that there may be several other cases where it might make
sense to either cancel the lazy load or complete it.  However, I have
not used or programmed that mode myself, and would think it more
appropriate if the author checked that.  I don't feel I know my way
around that one.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Problem with desktop.el

[Lars Hansen]

David Kastrup wrote:

>I think that there may be several other cases where it might make
>sense to either cancel the lazy load or complete it.  However, I have
>not used or programmed that mode myself, and would think it more
>appropriate if the author checked that.  I don't feel I know my way
>around that one.
>  
>
I don't remember who wrote the lazy load code, but I modified and
installed it.
I will take a look at your change.