readme.txt

open arj source

      A: As we have  stated earlier, ARJ reports  the size of its internal
         EA storage structure as the  EA size when archiving files. Across
         various platforms   (OS/2-16, OS/2-32, NT)  there are  various EA
         structures.  The system is   questioned for  the  actual  EA size
         during archiving.

      Q: How can I back up my OS/2 Workplace Shell folders, preserving the
         icons?
      A: Since  folders are  represented  with directories, you'll have to
         enable directory storage with -a1 or -hbfd.

      Q: The EAs have vanished after I used ARJ/DOS to update an archive.
      A: Current versions  of ARJ/DOS and ARJ32, as well as ARJ/2 prior to
         2.62.10, strip  the  extended  headers when  any kind  of archive
         update occurs.

      Q: I want  to  create  single-volume  self-extracting  archive  that
         supports EAs but ARJ/2 uses ARJSFX instead of ARJSFXV.
      A: You need to  force  use of  ARJSFXV/2. The best way for  it is to
         specify an arbitrary large value for volume size, e.g. -va.

      Q: How can I create an installer for my OS/2 product with ARJ?
      A: ARJSFX/2 is  able  to run OS/2  commands after unpacking archive.
         Try this: create a  script you want  to to be  invoked  after the
         installation completes.

         e.g., INSTALL2.CMD:
         =======
          /* REXX */

          if RxFuncQuery('SysLoadFuncs') then do
           call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
           call SysLoadFuncs
          end

          say "Installation has completed, creating desktop object..."
          call SysCreateObject ....
         ========
         and so on...

         Now create an archive comment with the first line as follows:
         )) \InstallDir\ -b -x -y -!INSTALL2.CMD

         Call it, for example, CMT.ANS. Now create an ARJSFX archive:

         ARJ a PACKAGE.EXE -je -r -a -jm -zCMT.ANS -xCMT.ANS

         You'll make  a  self-extracting  archive  with  an  automatically
         invoked installation program.

      Q: How can I distinguish between ARJ/ARJZ/ARJ32 archives?
      A: Use the ARJ V  command. The "Host OS" field contains  the type of
         host OS. The  "Revision"  field  may  be used  to  determine  the
         archiver version that added the file:

                 1 = ARJ versions earlier than 0.14,
                     ARJZ compatibility mode (-md is less than 26624)
                 2 = ARJ v 0.14...0.20
                 3 = ARJ v 1.00...2.22
                 4 = ARJ v 2.30, X1
                 5 = ARJ v 2.39a, 2.39b
                 6 = ARJ v 2.39c...2.41
                 7 = ARJ v 2.42a...2.50a
                 8 = ARJ v 2.55...2.61, ARJ/2 v 2.61
                 9 = ARJ v 2.62, ARJ/2 v 2.62, ARJ32 v 3.00
                10 = ARJ v 2.70 and higher, ARJ/2 v 2.62.10 and higher
                11 = ARJ with UNIX support (2.77/3.10 and higher)
                50 = ARJZ with maximum distance up to 32K
                51 = ARJZ with maximum distance up to 64K
               100 = ARJ32 v 3.00b...3.01
               101 = ARJ32 v 3.02 and higher

         Notes:

         1. ARJ versions  that created the  Revision 1 header have  used a
            different method 4 compression. Support for it  was dropped in
            versions 1.xx. Such  archives may  be incorrectly processed by
            @PRODUCT.

         2. ARJ v 2.76.07 and higher can  read the  newer UNIX time format
            of  ARJ  v  3.10/2.77. The  intention was  to make  the stable
            versions compatible with it.


   INFORMATION FOR DEVELOPERS

      The new UNIX time  format  can be identified  by "Host OS" equal  to
      "UNIX" or "NeXT", and "arj_nbr" greater than or equal to 11. In this
      case, all of the time fields in the  corresponding header are in the
      UNIX  time  format, i.e. 4-byte  value specifying number  of seconds
      passed since 01/01/1970, 00:00:00 UTC.

      By other means, the header format  is 100% compatible  with standard
      ARJ format, but we  utilize the  extended  header fields. Here  is a
      brief overview of this  technology. The extended header layout is as
      follows (all values are little-endian):

      Bytes  Description
      -----  -----------
          1  Extended header ID.
          1  Continuation  flag. If set to  0, marks the  end of  block
             chain so the header data can be concatenated and processed.
             Also it provides a way of checking for trashed blocks.
          ?  Header data.

      A standard CRC32 of the whole header, including the ID but excluding
      header size field,  is  appended to  it. It is strongly  recommended
      that the CRC is verified before any further processing occurs.

      ID 0x45 ('E') == Extended attributes
      ------------------------------------

      This is only valid if  the arj_nbr (header revision number) is 10 or
      greater.

      The packed  EA  block is a  complex  structure  that  can span  over
      multiple  volumes. In  case of  such  spanning,  separate  parts  of
      the block  are stored  in  separate extended  headers  on  different
      volumes and they must be joined together when the last block is read
      (it's recognized   by  EXTFILE_FLAG being clear). The layout of  the
      packed block follows:

      Bytes  Description
      -----  -----------
          1  Compression method (0...4, may differ from the  one found  in
             the file header)
          2  Unpacked EA data size in bytes
          4  CRC32 of unpacked EA data
          ?  Raw packed EA data

      The raw  packed data  may  be decompressed  using the  original  ARJ
      algorithms. In the case when the file is encrypted, the packed block
      is also  encrypted (but the  garble  routine is  reinitialized  when
      compression  of the EA occurs). The password modifier is the same as
      for the  first file section. After  decompression, the  following EA
      structure will exist:

      Bytes  Description
      -----  -----------
          2  Total number of EA records
          ?  Extended attribute records

      The extended attribute records are merged altogether. They should be
      processed sequentially. A single record  represents a single EA, and
      no EA can be represented twice. The layout is as follows:

      Bytes  Description
      -----  -----------
          1  fEA byte (may indicate a critical EA)
          1  Size of extended attribute name
          2  Size of extended attribute value
          ?  Extended attribute name (not ASCIIZ)
          ?  Extended attribute value (binary data)

      Even if the file is  a text  one, the EAs must be  handled as binary
      data during  compression and  extraction. When EAs are spanned  over
      multiple volumes, neither  the packed  block header  is repeated nor
      the compression  is  restarted (actually, the whole block  including
      its header is created in memory and later split to volumes).

      ID 0x4F ('O') == Owner information
      ----------------------------------

      Contains the owner  information, and possibly, group information, in
      character form. Valid if arj_nbr is 11 or greater.

      Bytes  Description
      -----  -----------
          1  Owner's name length.
          ?  Owner's name (non-ASCIIZ)
             OR
             Owner's name (ASCIIz), followed by
          ?  Group name (non-ASCIIz)
      
      ID 0x55 ('U') == UNIX special files
      -----------------------------------

      The UNIX special file entry is  a complex  freeform structure, valid
      if arj_nbr is 11 or greater:

      Bytes  Description
      -----  -----------
          1  Special file descriptor:
             Bits 0...4 = data size (0 allowed, 31 has a special meaning)
             Bits 5...7 = type:
                          000 = pipe
                          001 = hard link
                          002 = symbolic link
                          003 = block device
                          004 = character device
          ?  If the size field in descriptor  contained 31, then two bytes
             here contain the size, otherwise there is no area between the
             descriptor and data.
          ?  Raw data. Size is reported by the descriptor or the dedicated
             size field. Format:

		 Pipe:	Empty (size is zero).
		 Link:  Target file (non-ASCIIZ).
               Device:	The dev_t  structure  in the  host OS' format  and
                        endia order.
      
      ID 0x6F ('o') == Owner information (numeric)
      --------------------------------------------

      Contains the owner's UID and GID. Valid if arj_nbr is 11 or greater.

      Bytes  Description
      -----  -----------
          1  Data length (must be 8 for the current implementation).
          4  Owner's UID (little-endian).
          4  Owner's GID (little-endian).


   COMPATIBILITY ISSUES

      ARJ has  been  briefly tested  on the  following platforms  and file
      systems:

      DOS (FAT)

        MS-DOS v 2.11, 3.20, 3.21, 4.01, 5.00, 6.00, 6.20, 6.22
        PC DOS v 6.30, 7.00
        Windows 95, 98
        Windows NT Workstation v 3.51, 4.00

      OS/2 (FAT, HPFS, Ext2FS, JFS, NTFS)

        Microsoft OS/2 v 1.21
        IBM OS/2 v 1.30, 2.00, 2.10, 3.00, 4.00, 4.50
        OS/2 subsystem in Windows NT v 3.51, 4.00, Windows 2000

      Win32 (FAT, HPFS, NTFS)

        Windows 95, 98, ME
        Windows NT v 3.51, 4.00, Windows 2000, Windows XP

      Linux (UMSDOS, HPFS, Ext2FS, Ext3FS, JFS)

        Linux v 2.2.13/19-20, 2.4.5/18-21
        glibc v 2.1.2, 2.1.3, 2.2.3

      FreeBSD (FAT, UFS, HPFS)

        FreeBSD v 3.4/STABLE

      QNX (QNX4FS, FAT)

        QNX v 6.2.1/PE Patch B


      End of document