Re: A few questions about desktop.el

[Stuart D. Herring]

Way back in July 2005, this was part of a discussion about improving
desktop.el:

> Not-totally-unrelated: running two or more Emacs instances that use
> the same desktop file is a classical race condition; the last one to
> exit overwrites the desktop file (quite funny when the desktop was
> very elaborate and the last instance to exit uses almost no buffers).
>
> It'd be very useful to try to detect it and at least stop the second
> instance from loading and using the desktop file if it's already in
> use. There's no way to do that from Emacs, is there?

Richard later suggested using the file-locking primitives along with file
timestamps to implement this.  Here's a stab at implementing the collision
detection, but without file locking because I wasn't sure how to mix that
with `load' competently.  (I suspect this matters little since Emacs
sessions are quite unlikely to be actually _accessing_ the desktop file at
the same time.)

Two things are done: first, a desktop file is modified when it is read
(without incident) to include a "in use" tag; further Emacses will
complain about this if they see it, and will leave the desktop file
unloaded unless the user accepts the collision risk.

Second, when a desktop file is read or written, its modification time
(which is typically "now", since with this patch even loading the file
modifies it) is remembered; if it's different when the desktop is to be
saved, appropriate queries are posed.  (In particular, if no desktop file
is loaded, perhaps because the user decided not to re-load a file, any
attempt to save the new desktop over an existing desktop file will be
complained about.)

I'm certainly not proposing this for installation right now; it needs lots
more testing than I've given it (possibly by people who actually use
desktop), and my papers-issues aren't yet resolved.  But I encourage
people (in particular Juanma, who raised the issue) to try it and let me
know if it's any good; if the testing and the papers go okay, it'll just
need a ChangeLog entry to be good.

Enjoy,
Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

desktop-conflict.patch
Description: Binary data