From xemacs-m  Thu Apr 24 10:54:30 1997
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210])
	by xemacs.org (8.8.5/8.8.5) with SMTP id KAA26621
	for <xemacs-beta@xemacs.org>; Thu, 24 Apr 1997 10:54:29 -0500 (CDT)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id JAA27697; Thu, 24 Apr 1997 09:54:16 -0600
Received: by suomi (SMI-8.6) id JAA03560; Thu, 24 Apr 1997 09:54:16 -0600
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Cc: Hrvoje Niksic <hniksic@srce.hr>
Subject: Re: viewing gzipped tar file fails (19.15 & 20.1)
References: <9704240607.AA09175@ndsoft.com> 	<kigvi5ckjpu.fsf@jagor.srce.hr> <9704240721.AA10268@ndsoft.com> <kigrag0khm1.fsf@jagor.srce.hr>
Organization: CIRES, University of Colorado
X-Attribution: mb
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 24 Apr 1997 09:54:15 -0600
In-Reply-To: Hrvoje Niksic's message of 24 Apr 1997 09:25:10 +0200
Message-ID: <vkohb4l8m0.fsf@cdc.noaa.gov>
Lines: 52
X-Mailer: Gnus v5.4.45/XEmacs 20.1

>> On 24 Apr 1997 09:25:10 +0200,
>> Hrvoje Niksic(Hrv) wrote:

Hrv> Our version should work.  But it doesn't.

>> xemacs -q -no-site-file
>> (require 'crypt)
>> M-x find-file procmail.tar.gz
>> 
>> I get the binary characters.

Hrv> Bad bad bad.

I think I see the problem. The procmail tarball was evidently compressed
with zip, not gzip -- it's magic number is not consistent (output of file(1)):

  procmail-3.10.tar.gz: Zip archive data, at least v2.0 to extract

cf.

  pixy3.2.tar.gz: gzip compressed data, deflated, last modified: Thu  Mar 28 12:00:00 1996, os: Unix

crypt.el, in contrast to jka-compr, uses magic numbers to identify the 
file contents. Consequently, for this case, crypt fails to decompress
it with gzip (even though gzip will decompress this singel-member
archive). jka-compr just uses the filename extension. So, that is why

xemacs -q -no-site-file
(require 'jka-compr)
M-x find-file procmail.tar.gz

works fine.

Since crypt.el is an orphan and broke, I think it falls under Kyle's
critera for removal. That, or someone should step up, adopt it and fix
it. I don't think it's a hard problem to fix, but I don't want to take 
on the maintenance responsibility myself.

Personally, I stripped out the compression stuff in crypt.el,
and use it just for encryption/decryption, since I prefer the way
jka-compr can append to gzipped files without decompressing them. It
has peacefully coexisted with jka-compr and tar mode in this
setup.

Kyle, before crypt++.el came along, I think you were the original
maintainer of crypt.el. Did that original version just do
encryption/decryption? Is it still a viable alternative? Is there any
interest in a crypt-lite.el that just does encryption/decryption as in
my setup?

-- 
  -mb-

