Re: [found the culprit]

[Davis Herring]

> `Z' should be its own inverse.

This is a reasonable principle, but there is a reason to deviate from it 
here.  The uncompressed tar format is so rarely used (partly because of 
the lack of actual tape drives, and partly because of change in the 
relative cost of CPU cycles and storage space) that having a convenient 
key to get _to_ it is unimportant.  The unpacked and compressed-tar 
states, however, are both deserving of such a key.  Therefore, whatever 
behavior (unpack or compress) we choose to apply to a .tar will not be 
inverted by a second Z -- because the initial state is presumed to be 
undesirable.

For example, on some machines I use, "git archive" cannot produce 
compressed archives.  Having Z compress its raw .tar output would be, to 
me, a useful way of working around that limitation.  But other users 
might prefer that Z unpack a .tar -- and then repack the resulting 
(hopefully single) directory into a .tgz.

Could Z query for which behavior to use in this (rare) case?  That would 
provide an intuitive reason why a second Z would not necessarily reverse 
the process.  (The query could even say so explicitly if it helped.)

> Is it hard to hit two keys to uncompress + unpack?

Yes, because the operations are frequently slow and you wouldn't want to 
have to input a second key after a delay (or blindly).

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.