El 28/03/2013 1:06, Ewald escribió:
Google found an old thread on lazarus mailing list about this ("FPC,
gzip and stream") but without any solution, everything mentioned there
has either the limitations of TCompressionStream/TDecompressionStream
(no gzip format) or TGZFileStream (not able to work wit ObjectPascal
streams).
Hello,
.gz is a quite simple format, but it can not be implemented as a TStream (only)
descendant because in a single .gz file many files could be added so something
like the class to handle .zip files should be used.
Sorry to just drop in on this quite late, but isn't gzip a compression algorithm and not a
file format as such? gzip (the command line utility) only compresses one file and *doesn't*
put this in a multi-file container. To get `multi-file gzips`, you will first want to
bundle the files and compress this bundle (files -> tar -> gzip) or compress the
files separately and then bundle them together (files -> multiple separate gzipped files
-> tar). Or are we talking about a different gzip here?
Hello,
Just quoting the RFC1952 about .gz format:
--- http://tools.ietf.org/html/rfc1952 --------
2.2. File format
A gzip file consists of a series of "members" (compressed data
sets). The format of each member is specified in the following
section. The members simply appear one after another in the file,
with no additional information before, between, or after them.
-----------------------------------------------
So I think it is legal to concatenate several .gz files and get a final
.gz with several files inside.
In the other hand, yes, the usual behavior in .gz is to store only one file.
--
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
