bug#10708: 24.0.93; desktop.el doesn't restore buffers visiting files in archives

bug#10708: 24.0.93; desktop.el doesn't restore buffers visiting files in archives

[Eli Zaretskii]

 emacs -Q
 C-x C-f emacs-24.0.93.tar.gz  ;; or any other archive
 <in the file listing, go to the line of some file and type RET>
 M-x desktop-save RET RET
 C-x C-c

 emacs -Q
 M-: (desktop-read "/directory/where/you/saved/it/above") RET

Expected result: buffers for both the tarball and the file you were
looking at when you typed "C-x C-c" above are restored.

Actual result: the buffer with the tarball is restored, but the buffer
with its member is not.  A message in the echo area tells that 1 buffer
"failed to restore".  In *Messages*, you will see a message saying
something like

  Desktop: File "/home/e/eliz/emacs-24.x/emacs-24.0.93.tar.gz!emacs-24.0.93/lib/strftime.h" no longer exists.

IOW, desktop.el does not realize that this form of file names means an
archive member, and therefore does not extract that member when
restoring the desktop.


In GNU Emacs 24.0.93.3 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2012-02-02 on fencepost.gnu.org
Configured using:
 `configure '--enable-asserts' '--enable-checking' '--with-gif=no'
 '--with-tiff=no' 'CFLAGS=-O0 -ggdb -g3 -DGLYPH_DEBUG=1''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC [ > 0 ; 1 3 6 ; 0 c ( d e s k t o p - r e a d SPC 
" ~ / e m a c s - 2 4 . x " ) C-j y C-x b * M e s TAB 
RET ESC x r e p o r t - e m TAB RET

Recent messages:
("./bzr/emacs/trunk/src/emacs")
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading cc-mode...done
Desktop: File "/home/e/eliz/emacs-24.x/emacs-24.0.93.tar.gz!emacs-24.0.93/lib/strftime.h" no longer exists.
Loading tar-mode...done
File emacs-24.0.93.tar.gz is large (48MB), really open? (y or n)  y
uncompressing emacs-24.0.93.tar.gz...done
Parsing tar file...done
Wrote /home/e/eliz/emacs-24.x/.emacs.desktop.lock
Desktop: 1 buffer restored, 1 failed to restore.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug jka-compr tar-mode cc-mode cc-fonts easymenu cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt desktop
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dynamic-setting font-render-setting move-toolbar
gtk x-toolkit x multi-tty emacs)

bug#10708: 24.0.93; desktop.el doesn't restore buffers visiting files in archives

[Stefan Monnier]

> IOW, desktop.el does not realize that this form of file names means an
> archive member, and therefore does not extract that member when
> restoring the desktop.

Of course, the "right" fix is to implement a file-name-handler
for tarballs (and other archives),


        Stefan

bug#10708: 24.0.93; desktop.el doesn't restore buffers visiting files in archives

[Kevin Rodgers]

On 2/3/12 6:39 AM, Stefan Monnier wrote:
>> IOW, desktop.el does not realize that this form of file names means an
>> archive member, and therefore does not extract that member when
>> restoring the desktop.
>
> Of course, the "right" fix is to implement a file-name-handler
> for tarballs (and other archives),

Is "archive!member" a good syntax?  i.e. what about regular files that have "!"
in their name?  (not to mention archives or archive members that have "!" in
their name)

-- 
Kevin Rodgers
Denver, Colorado, USA

bug#10708: 24.0.93; desktop.el doesn't restore buffers visiting files in archives

[Eli Zaretskii]

> From: Kevin Rodgers <kevin.d.rodgers@gmail.com>
> Date: Fri, 03 Feb 2012 07:48:03 -0700
> 
> On 2/3/12 6:39 AM, Stefan Monnier wrote:
> >> IOW, desktop.el does not realize that this form of file names means an
> >> archive member, and therefore does not extract that member when
> >> restoring the desktop.
> >
> > Of course, the "right" fix is to implement a file-name-handler
> > for tarballs (and other archives),
> 
> Is "archive!member" a good syntax?

We are using it for a long time, and no one ever complained.

> i.e. what about regular files that have "!"  in their name?

desktop.el will need to look for a literal file first, and only then
for an archive member.

> (not to mention archives or archive members that have "!" in their
> name)

That is already handled, AFAIR.

bug#10708: 24.0.93; desktop.el doesn't restore buffers visiting files in archives

[Stefan Monnier]

>> >> IOW, desktop.el does not realize that this form of file names means an
>> >> archive member, and therefore does not extract that member when
>> >> restoring the desktop.
>> > Of course, the "right" fix is to implement a file-name-handler
>> > for tarballs (and other archives),
>> Is "archive!member" a good syntax?

I don't know.

> We are using it for a long time, and no one ever complained.

That's because currently we don't handle such files specially, but with
a file-name-handler for it we would need to be careful not to trigger
the file-handler for non-archives.


        Stefan