This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brandon-rhodes
Recipients Ankur.Ankan, berker.peksag, brandon-rhodes, eric.araujo, ezio.melotti, kyle, larry, lars.gustaebel, rhettinger, serhiy.storchaka, vstinner
Date 2013-03-20.03:04:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <87wqt293h3.fsf@asaph.rhodesmill.org>
In-reply-to <1363713014.4.0.948787304959.issue13477@psf.upfronthosting.co.za> (Larry Hastings's message of "Tue, 19 Mar 2013 17:10:14 +0000")
Content
Larry Hastings <report@bugs.python.org> writes:

> Huh.  tar *can* infer it from the data itself.  On the other hand, it
> chooses explicitly not to.  I guess "tar" knows explicit is better
> than implicit too ;-)

I am told that the refusal of "tar" to introspect the data is because:

(a) Tar runs "gunzip -c" (for example) as an external program; it does
not actually compile against libz.

(b) Streams in UNIX cannot be rewound.  Tar cannot look at the first
block of an input pipe and then "put the block back" so that the same
input can be fed directly to "gunzip" as its input.

(c) Given (a) and (b), tar could only support data introspection of
input from a pipe if it were willing to be a pass-through that, after
reading and introspecting the first block, then fired up "gunzip" and
sent ALL of the blocks through.  Which would require multiprocessing,
threading, or async I/O so that tar could both read and write, which
would make tar more complicated.

(d) Therefore, tar refuses to even look.

Since Python does bundle compression in its standard library, it can
quite trivially step forward and actually do the data introspection that
tar insists on not doing; the first few bytes of a tar archive are quite
demonstrably different from the first bytes of a gzip stream, if I
recall.
History
Date User Action Args
2013-03-20 03:04:10brandon-rhodessetrecipients: + brandon-rhodes, rhettinger, lars.gustaebel, vstinner, larry, ezio.melotti, eric.araujo, kyle, berker.peksag, serhiy.storchaka, Ankur.Ankan
2013-03-20 03:04:10brandon-rhodeslinkissue13477 messages
2013-03-20 03:04:09brandon-rhodescreate