Path: utzoo!attcan!uunet!wuarchive!udel!princeton!cs!nfs
From: nfs@cs.Princeton.EDU (Norbert Schlenker)
Newsgroups: comp.os.minix
Subject: Re: LHARC available for MINIX!
Summary: Maybe it will work, maybe it won't
Keywords: lharc archive compress
Message-ID: <784@rossignol.Princeton.EDU>
Date: 3 Jul 90 15:21:24 GMT
References: <1990Jul2.143113.2267@jarvis.csri.toronto.edu> <781@rossignol.Princeton.EDU> <1990Jul3.011235.5774@jarvis.csri.toronto.edu>
Sender: news@cs.Princeton.EDU
Organization: Dept. of Computer Science, Princeton University
Lines: 55

In article <1990Jul3.011235.5774@jarvis.csri.toronto.edu> wayne@csri.toronto.edu (Wayne Hayes) writes:
>In article <781@rossignol.Princeton.EDU> nfs@cs.Princeton.EDU (Norbert Schlenker) writes:
>>LHARC wasn't written with portability in mind.  The archive header
>>format is dependent on byte order within words and on the length of
>>integers.  A PC archive cannot be read on an ST and vice versa,
>>without considerable pulling of teeth.
>
>Have you actually tried this?  I'm sorry but I think you're wrong about
>this.  Yes, the headers weren't written with portability in mind, but
>the UNIX source I'll be posting handles this very well...

Here is the Lharc header structure from the Unix source that I have.  It
is possible that this structure is from an old version, but this is from
the most recent posting in comp.sources.misc.

typedef struct LzHeader {
  unsigned char		header_size;
  char			method[METHOD_TYPE_STRAGE];
  long			packed_size;
  long			original_size;
  long			last_modified_stamp;
  unsigned short	attribute;
  char			name[256];
  unsigned short	crc;
  boolean		has_crc;
  unsigned char		extend_type;
  unsigned char		minor_version;
  /*  extend_type == EXTEND_UNIX  and convert from other type. */
  time_t		unix_last_modified_stamp;
  unsigned short	unix_mode;
  unsigned short	unix_uid
  unsigned short	unix_gid;
} LzHeader;

This header CANNOT be portable between machines.  It depends on the
size of short integers (usually 16 bits, but they don't have to be),
on the size of long integers (usually 32 bits, but ...), on the
endianness of the machines which read and write the archive, on the
padding between structure elements, and on the fact that Unix modes,
uids, and gids all fit into unsigned short integers.

These assumptions cannot be guaranteed, even on the limited range of
machines that Minix runs on.  They are certainly not guaranteed in the
Unix range.  Lharc archives produced with the above header on my PC
can be read on a VAX here.  The same archive cannot be read on a Sun-4
(byte order and structure padding problems) nor a DEC 5400 (an endian
and structure padding problem) nor a MIPS box (a structure padding
problem).  I have little hope that they will be readable on the next
fast box that is installed here.

The solution is a more portable form of header.  As I suggested before,
something like a TAR header, cut back in size from 512 bytes, will be
necessary.  Without that, this archive format will not fly.

Norbert