[tex-live] volunteer to implement lcab compression?

Thomas J. Kacvinsky tjk at ams.org
Tue Jun 8 21:33:12 CEST 2004

Personally, I like the .pkg format of MacOS X with its BOM (bill of
materials, giving us the granularity we need for permissions of
files/directories), and its use of pax.  Only problem is that the
BOM format doesn't support LFS.  Not that we have a 4 GB file in

And it so happens thaat mkbom and pax are part of *BSD variants, so
the source code is out there (to be ported to whichever platforms).

Or are we looking at CAB files for the MSI installer Fabrice is
working on?



On Tue, 8 Jun 2004, Olaf Weber wrote:

> Manfred Lotz writes:
> > On Tue, 8 Jun 2004 19:33:55 +0200
> > Thomas Esser <te at dbs.uni-hannover.de> wrote:
> >>> We (Sebastian and I) have not found any other programs to write .cab
> >>> files under Unix (many programs support reading .cab's).  There is a
> >> Is the file format good enough to preserve file attributes such as
> >> UNIX permissions?
> > Cab format is intended for Windows platform. Therefore it doesn't know
> > about permissions and ownership.
> The format allows for additional data to be stored per cab file header
> (CFHEADER), folder header (CFFOLDER), and data block (CFDATA), but not
> per file header (CFFILE).
> However, the additional data in a folder header is the same size for
> all folders in the CAB file.  And the same goes for the additional
> data per data block.
> A data block can contain data of more than one file.
> All of which taken together means that there is no really suitable
> place to put additional per-file data in a CAB file -- you'd have to
> resort to indirect methods like packaging an additional "file" with
> the data.
> In all it is not a very good distribution format for unix-like
> systems.
> >> Is the file format smart enough to handle text files
> >> properly(i.e. convert line ends on extraction)?
> > I'd say yes because CABARC.EXE seems to treat files as binary.
> Um, this means "no" as Thomas was asking about automatic translation
> of NL to CRNL or CR, and all that.  And the answer is that for CAB
> extractors the CAB file really contains a number of bytestreams, which
> are not interpreted or changed.  (Personally, I like that.)
> Basically, CAB does some tricks to get better compression than ZIP
> will for the case with many small files, and is as far as I can tell
> about equal on large files.
> --
> Olaf Weber
>                (This space left blank for technical reasons.)
> _______________________________________________
> TeX Live mailing list
> http://tug.org/mailman/listinfo/tex-live

More information about the tex-live mailing list