bug#8870: Package installer corrupts image & zip files

[Jambunathan K <kjambunathan@gmail.com>]

Chong Yidong <cyd@stupidchicken.com> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> I distribute an image file (png) and a OpenOffice extension (oxt) file
>> as part of the bundle. These files are getting mangled by the package
>> installer.
>
> I can't reproduce this, either with the org-odt package at your URL, nor
> with a simple multi-file package containing a gif and a png file.
>
> It's possible this is some kind of Windows problem related to tar mode.
> Can you trying visiting the tar file in Emacs, and see if the image is
> untarred correctly?
>
> C-x C-f org-odt-XXXX.tar
> C-s .png RET
> RET
>
> Is the image displayed correctly here?

The above sequence (which uses tar-extract) DTRT.


1 Hint for the final fix 
-------------------------

tar-untar-buffer needs to use the right coding system for
extraction. 

For example, the following "stupid change" in `tar-untar-buffer' fixes
the original bug.


  (let ((coding-system-for-write 'no-conversion)) 
    (write-region start end name))


2 Observation 
--------------
1. Visiting the png file embedded within the original tar file is OK
2. Visiting the png file in the
   ~/.emacs.d/elpa/org-odt-YYYYMMDD/contrib/odt/files/org-mode-unicorn.png
   is NOT OK.


3 Analysis 
-----------

3.1 Behaviour of tar-untar-buffer 
==================================

1. `package-install-file' uses `tar-untar-buffer' for extraction.
2. `tar-untar-buffer' invokes `write-region' and an immediate query
   for `last-coding-system-used' reports "raw-text-dos" for the png
   file.

3.2 Behaviour of tar-extract 
=============================

1. `tar-extract' uses `decode-coding-region' with coding set to
   `no-conversion' for the png file. The coding is decided by a prior
   call to `set-auto-coding'.

   I would assume that a value of `no-conversion' is picked from the
   following entry in `auto-coding-alist'.


  ("\\.\\(jpe?g\\|png\\|gif\\|tiff?\\|p[bpgn]m\\)\\'" . no-conversion)


Jambunathan K.