* Apple IIgs (planned)
* Archimedes
* Atari ST (currently in development)
* Commodore Amiga
* Microsoft Windows
* Macintosh
* MSDOS
* OS/2 (16 and 32-bit versions)
* OS/2 Presentation Manager (currently in development)
* Primos (planned)
* UNIX
* VMS (currently in development)
* Any other system which people offer to port it to
In addition HPACK has built-in internationalization support (inasmuch as the system on which it is running will allow), allowing easy creation of multi-language versions. Currently Dutch, English, German, and Italian versions of HPACK exist.
Note: This documentation is intended mainly as an alternative to the proper documentation which is in Postscript format. If possible the proper documentation should be used.
HPACK is run with the following command:
HPACK command [-options] archive [filenames.....][@scriptfiles.....]
Allowed commands are:
[A] - Add files to an archive.
[X] - Extract files from an archive.
[V] - Display a directory of files inside an
[P] - View files within an archive.
[T] - Test the integrity of an archive.
[D] - Delete files from an archive.
[F] - Freshen files to an archive.
[R] - Replace files in an archive.
[U] - Update files to an archive.
Allowed options are:
-0 - Store files without attempting any compression.
-a - Store file attributes.
-b - Specify a base pathname for all files.
-c - Encryption options (conventional and public-key encryption).
-d - Directory options (Mkdir, Rmdir, Mvdir, path options etc).
-e - Add/use error recovery information.
-f - Force file move into/out of an archive.
-i - Interactive mode (prompt for all actions).
-k - Overwrite existing archive.
-l - Security options (data authentication)
-m - Create a multipart archive.
-o - Overwrite on extraction options (All, None, Prompt, Smart).
-r - Recurse through subdirectories.
-s - Run in stealth mode.
-u - Unified compression mode.
-v - View files options (Files, Directories, All).
-w - Treat files as archive comments.
-x - Text file translate options (see below).
-z - Extended options (system-specific, see below).
Commands, options, and archive and file names may be given in upper or lower case (they are given in uppercase in the examples which follow merely for consistency). Options may be lumped together or may be given seperately preceded by the '-' delimiter. The option '--' may be used to indicate that no more options are present on the command line, following the standard Unix convention.
The default archive extension is '.HPK'. HPACK will always add this extension (provided the underlying filesystem supports it), changing any other given extension if necessary. Note that some quantum physics theories suggest that when the user is not directly observing the HPACK archive, it may cease to exist or will exist only in a vague and indeterminate state; in this case the existence of the '.HPK' extension cannot be guaranteed.
The filenames field may consist of zero or more filenames, defaulting to all files if no filenames are given (in other words archive all files in the current directory, or dearchive/view all files in the archive). HPACK uses UNIX-style wildcards (which are described in more detail below in the section "HPACK Wildcards"), as well as UNIX-style pathnames in place of the usual ones used by the systems' command interpreter, so that for example the path:
/TEMP/WORK/FILES
is used instead of the MSDOS equivalent:
TEMPWORKFILES
or the VMS equivalent:
[TEMP.WORK]FILES
If any additional components are needed, such as drives, network nodes, or devices, these can be specified in the manner usual to the host command interpreter. For example if the path in the above example were on drive A: under MSDOS the pathname would be:
A:/TEMP/WORK/FILES
If the path in the above example were on the 'HOME' node, on device 'DISK1' under VMS, the pathname would be:
HOME::DISK1:/TEMP/WORK/FILES
The scriptfiles are names of files preceded with an '@' character. When HPACK encounters one of these it will treat the filename as a file containing a list of files to process. Script files and normal filenames may be freely mixed on the command line. See the section "HPACK Script Files" below for more information.
When HPACK scans any filename that has been given to it, it will check for the presence in the filename of any of the special characters:
* ? [ ]
If one of these is detected, then the string of characters making up the
If one of these is detected, then the string of characters making up the
filename will be treated as being a pattern for a filename, rather than the
name of a specific file. These special characters have the following meanings
when used in a filename string:
The case-sensitivity when handling filenames depends on the operating system HPACK is being run under. On the Atari ST and under MSDOS and VMS, filenames are converted to uppercase, but are not case-sensitive; on the Amiga and Archimedes and under OS/2, filenames are left as is, but are also not case sensitive (so that "FileName" will match "Filename", "FILENAME", and "filename"); and under Unix, filenames are left as is, and are case sensitive, so that "makefile" and "Makefile" are treated as seperate names.
These wildcards can be combined to create quite powerful expressions. For example, to match any file not beginning with an 'a', 'b', 'c', or 'f', and containing at least two characters, the required expression would be:
[^a-cf]?*
where the [^a-cf] would match anything but 'a', 'b', 'c', or 'f'; the '?' would match the second character required, and the '*' would match any remaining characters.
For example, if we have an archive whose contents are:
file1.txt file2.txt file3.txt file4.txt file5.txt file6.txt file7.txt file8.txt file9.txt Index.txt we could perform the following file matches on it:
Example: To add all files in the current directory to the archive ARCHIVE.HPK in the current directory:
HPACK A ARCHIVE
File already exists - overwrite [y/n/a]
extraction of this file, and 'A' will process all files from this point as if a extracted will need to be translated to allow for the naming conventions of different operating systems. In these cases the original name will be printed, followed by the name it will be extracted under.
On Apple systems data is divided into two sections in a file, a "data fork" and a "resource fork". Under non-Apple operating systems only the data fork will be extracted from an archive: the resource fork (which only Apple systems can make any use of) will be skipped.
Example: To extract all files in ARCHIVE.HPK not beginning with an 'A' to the current directory:
HPACK X ARCHIVE [^A]*
HPACK - The multi-system archiver Version 0.78a0 (shareware version)
For Amiga, Archimedes, Atari ST, Macintosh, MSDOS, OS/2, and UNIX
Copyright (c) Peter Gutmann 1989 - 1992. Release date: 1 Sept 1992
Archive is 'ARCHIVE.HPK'
System Length Size Ratio Date Time Name
------ ------ ----- ----- ---- ---- ----
MSDOS 18537 6217 66% 04/05/90 11:32:48 README.TXT
Atari 8301 3169 74% 27/12/90 21:02:39 LZSS.EXE
UNIX 30061 9127 70% 24/11/89 16:52:57 compr.method.txt
OS/2 8481 3282 61% 22/12/90 08:58:52 Comp.test
Mac 0 0 0% 01/07/91 18:20:20 Fast LZ Decoder using B..
------ ------ ------ ----- ----
65380 21795 67% Total of 5 files
Done
The archive used is displayed, followed by a list of all the files within the archive. The fields for each file inside the archive are as follows:
9
System:
The system the file was archived under.
9
Length:
The length of the file when unarchived.
9
Size:
The size of the compressed file within the archive.
9
Ratio:
The ratio of the compressed file to the uncompressed file.
9
Date:
The creation date of the file within the archive.
9
Time:
The creation time of the file within the archive.
9
Name:
The name of the file within the archive. If the name is too long to fit on the
screen then a '..' is appended to indicate this. In addition files may have a
single character prepended to them: an asterisk '*' before the name indicates
that this file has been encrypted, a dash '-' indicates that it includes
authentication information, and a hash '#' indicates that it is both encrypted
and includes authentication information.
Note that the name within the archive may not be the same as the name given to
the unarchived file since translation may be necessary to allow for the naming
conventions of different operating systems.
Note also that in the example above the file originating on the Macintosh has a
length of zero bytes. This does not necessarily mean the total data size is
zero bytes, since files originating on Apple systems have a second block of
data called a resource fork which contains code and other program resources.
These resources are only useful on Apple systems and are not shown as part of
the total file size on other systems.
Finally the total length of all files within the archive, uncompressed and compressed, the overall compression ratio for the archive, and the number of files within the archive, is given. If any filespecs are given, only files which match those filespecs will be displayed. This is useful when you only want to extract certain files and would like to see how much space they will use.
If more than one archive is viewed, a grand total of the size and number of files in all the archives viewed is printed. The type of information printed may be controlled by using the view options (which are explained in the section "HPACK Options" below). The default is to print all files and directories in the root directory of an archive. If the root directory contains no files or directories matching the given filenames and/or wildcards, the error message "No matching files in archive" will be printed. To recursively display the contents of all subdirectories, either the [-r]ecurse subdirectories option or the wildcard string '*/*' should be used.
Example: To view the contents of any archives in the current directory
HPACK V *
HPACK P DATA CONTENTS.DOC | LPR
will send the file CONTENTS.DOC from within the archive DATA.HPK to the printer, and:
HPACK P DATA DESCRIPTION.DOC | MORE
will display the file DESCRIPTION.DOC with page breaks on your screen. Note that trying to display non-text files in this manner can be interesting, if not terribly productive.
Example: To display the file README.TXT from within the archive ARCHIVE.HPK:
HPACK P ARCHIVE README.TXT
Warning: File may be corrupted
Otherwise HPACK will display:
File tested OK
If, when all files have been tested, there were corrupted files, HPACK will print the total number of corrupted files:
Warning: n files were corrupt
where n is the number of corrupted files.
Note that this test is also performed automatically on extracting a file from an archive.
Example: To test the integrity of all MSDOS executable files in the archive ARCHIVE.HPK:
HPACK T ARCHIVE *.COM *.EXE
I all files are deleted from an archive (leaving an empty archive), HPACK will delete the archive as well.
Example: To delete all Pascal program files (a commendable move) from the archive ARCHIVE.HPK:
HPACK D ARCHIVE *PAS
Archive is uptodate
and exit.
Example: To freshen all files in the archive ARCHIVE.HPK:
HPACK F ARCHIVE.HPK
Example: To replace all the files which begin with the letters A-G in the archive ARCHIVE.HPK with their couterparts on disk:
HPACK R ARCHIVE [A-G]*
Example: To update the archive ARCHIVE.HPK with all files from the directory B:/DATA/JUNK:
HPACK U ARCHIVE B:/DATA/JUNK
Note that the last four options need to create temporary work files on disk. Thus it is necessary to have at least twice as much free disk space to work with as the total length of the archive. All other options use only the archive file, so it is possible to use them with minimal free disk space.
HPACK will attempt to translate the attributes of files from different systems into equivalent file attributes for the local system. This has varying degrees of effectiveness: Many of the Apple IIgs, Atari ST, Macintosh, MSDOS, and OS/2 attributes are equivalent so a direct translation is possible; the Amiga, the Apple IIgs, the Archimedes, Unix, and VMS also have some of the read/write attributes in common, and have a rough equivalent of a read-only file attribute in these attributes; and QNX 2.x/3.x has no equivalent file attributes.
If the [-d]irectory path store option is used HPACK will also store directory attributes, and set the directory attributes to the stored values when creating the directories on extraction.
Example: To extract all files in the root directory of the archive ARCHIVE.HPK, restoring all possible attribute information:
HPACK X -F ARCHIVE
Example: To extract all files in the archive ARCHIVE.HPK to the directory D:/OUTPUT/DATA:
HPACK X -BD:/OUTPUT/DATA ARCHIVE
Example: To add the files FILE1, FILE2, TEXT, and PROGRAM.EXE, all in the directory D:/JUNK/DATA, to the archive ARCHIVE.HPK:
HPACK A -BD:/JUNK/DATA ARCHIVE FILE[1-2] TEXT PROGRAM.EXE
Example: To add the files in C:/JUNK/DATA/FILES to the archive ARCHIVE.HPK inside the archive directory DATA/FILES:
HPACK A -BC:/JUNK ARCHIVE DATA/FILES/*
By default HPACK will encrypt entire archives (rather than just the files in them), meaning that not even the archive directory can be read by someone who does not have the decryption password.
The encryption options are divided into two classes, those employing conventional-key encryption and those employing public-key encryption:
5
-c
Use conventional-key encryption to encrypt the entire archive, the same as
[-c]rypt [a]ll.
5
-ci
Encrypt individual files using conventional-key encryption. The use of this
option is not generally recommended as it is not quite as secure as the
standard [-c]rypt [a]ll option. It is however useful when only a few files
need to be encrypted, the rest being subject to constant change which makes
encrypting them impractical.
5
-ca
Encrypt entire archive. This will encrypt not only the files themselves but
all additional data associated with them (attributes, icons, and so on), as
well as the archive directory information. The only remaining accessible data
is a small amount of archive identification information needed to allow HPACK
to process the archive.
5
-cs
Prompt for second password to access archive data. This allows the archive
directory to be encrypted with one password, and files to be encrypted with
another password. This option is useful if it is desirable to give a group of
users access to the archive directory but not to the files themselves, since
the contents of the archive can be made available with the first password, but
a second password is required to access the files themselves.
5
-cpi<userID>
Encrypt individual files using the public key which matches the given userID.
The public-key-encryption equivalent of the [-c]rypt option. This option is
not recommended if more than a small number of files are present in an archive
due to the amount of time needed to perform each public-key decryption
calculation.
5
-cpa<userID>
Encrypt the entire archive using the public key which matches the given userID.
The public-key-encryption equivalent of the [-c]rypt [a]ll option.
5
-cps<userID>
Encrypt the archive with a secondary public key which matches the given userID.
The public-key-encryption equivalent of the [-c]rypt [s]econdary option.
When processing an encrypted archive, all that is necessary is to tell HPACK to handle encrypted data by specifying the [-c]rypt option. HPACK will determine the encryption type and prompt for passwords as necessary as it processes the archive. If the archive is public-key encrypted and the recipients secret key is protected by encryption, HPACK will prompt:
Please enter password for secret key (8..80 characters)
If an incorrect password is given, HPACK will warn:
Password is incorrect.
and allow the password to be reentered. Up to three attempts at the password are allowed before HPACK gives up.
When searching for the key corresponding to a given userID, HPACK will perform a case-insensitive match of the given userID against any part of the keys userID. This means that only a partial userID need be given on the command line, and HPACK will use the first key for which the partial userID matches. This makes specifying the userID easier since the entire ID need not be given, but also means care should be taken if there are several similar userID's (all of which may match a certain userID fragment) in a collection of keys.
If there is a chance that the userID is ambiguous, the key can also be specified by its keyID using the standard C programming language format for hexadecimal values namely a prefix of '0x' and then the value itself. The keyID is the 6-digit hexadecimal value displayed for the key. As with userID's, HPACK will perform a case-insensitive match against any part of the full keyID.
HPACK will also allow the public-key encryption of data for multiple recipients, meaning that a single encrypted archive can be sent to an arbitrarily large number of recipients. This allows archives to be distributed to working groups or via mailing lists without necessitating a seperate encrypted archive for each recipient. Note that there is a slightly increased risk involved in this process since the chain of intended recipients is only as strong as its weakest link - only one of the private keys needs to be compromised to render the encrypted data insecure.
Multiple recipients are currently specified as a comma-seperated list of standard userID's or keyID's. There are moves afoot to add a mailing-list capability to the public keyring format which will be fully supported by HPACK if it eventuates.
Example: To encrypt the entire archive ARCHIVE.HPK, leaving only a small amount of identification information readable:
HPACK A -C ARCHIVE
Example: To encrypt all files to be added to the archive ARCHIVE.HPK:
HPACK A -CI ARCHIVE
Example: To encrypt the entire archive ARCHIVE.HPK with the archive directory readable by "TheMunsters" but the archive data itself only readable by "UncleFester" or "CousinItt":
HPACK A -CPATheMunsters -CPSUncleFester,CousinItt ARCHIVE
Example: To encrypt the file BASEBALL.BAT in the archive ARCHIVE.HPK with the key corresponding to the hexadecimal keyID A72F3B, taking advantage of the fact that HPACK will match any fragment of the ID:
HPACK A -CPI0x2F3 ARCHIVE BASEBALL.BAT
Note that the public-key decryption process can take a long time, especially when it must be performed multiple times (for example when the [-c]rypt [p]ublic-key [i]ndividual files option is used). HPACK will display the message:
One moment...
whenever it performs the calculations involved in public-key decryption. This process can often take significantly longer than one moment - on slower machines HPACK may appear to have ground to a halt as it performs the public-key decryption operation. Unless there is a special need for it, the use of conventional-key encryption is recommended.
One advantage of public-key encryption is that the key management is automatic - there is no need to enter passwords to perform the encryption and decryption operations. When passwords must be entered manually for conventional-key encryption, there is a chance that an incorrect password will be entered by mistake. If this happens for archive directories, HPACK will warn:
Warning: Archive directory corrupted, probably due to
9
incorrect password. Continue (y/n)
Since the password was incorrect, the archive directory information has been decrypted incorrectly. The 'No' option should be selected and the password reentered.
If this happens for archived files, the files will not be extracted properly:
Warning: File may be corrupted
Again, the password should be reentered when HPACK is re-run.
HPACK will add directories traversed only if there are files contained in them. To add all directories regardless of whether they contain files or not, use the [-d]irectories [a]ll option (see below).
Example: To add all files in all directories, along with the directories themselves, in and below the current directory to the archive ARCHIVE.HPK:
HPACK A -RD ARCHIVE *
The extended directory options are are as follows:
<Note: Some of these aren't implemented yet: Feedback on whether this way of
doing things is a good idea or not would be appreciated>.
5
-dm
Mkdir: Create the given directories.
<Not yet implemented - if necessary this can be faked by using 'hpack a -da
<path> <non-matching filespec>' where path is the new directory to add and the
non-matching filespec ensures that only the new directory, but none of the
files in it, are added>
5
-dr
Rmdir: Delete the given directories.
<Not yet implemented>
5
-dv
Mvdir: Move the given directory into the second given directory.
Warning: Through injudicious use of this command it is possible to create
circular directory references, or to cut off entire directory trees. Do not
try to move directories into subdirectories of themselves! (Or should HPACK
check for this??)
<Not yet implemented>
5
-da
Store/extract all directories scanned, even if they contain no files. This
option is useful for storing entire filesystems inside archives and restoring
entire directory trees from archives.
5
-dn
Do not create the directory inside the archive if it doesn't already exist. If
an attempt is made to add a file to a nonexistent directory, HPACK will exit
with the error message:
Path not found
5
-dc
Create only immediate containing directory for a group of files, not the entire
directory path. This is mainly for use by GUI versions of HPACK to allow
extraction of individual directories, folders, or drawers (depending on what
the host operating system calls them) of files.
Example: To delete the directory DATA/JUNK inside the archive ARCHIVE.HPK:
HPACK A -DR ARCHIVE DATA/JUNK
Note the use of the [A]dd command as a dummy command: In this case the main command is ignored and only the directory option is used (ICK!).
Example: To move all files and directories in and below DATA/JUNK in the archive ARCHIVE.HPK into the directory STUFF:
HPACK A -DV ARCHIVE DATA/JUNK STUFF
Example: To add all files and directories (even empty ones) in and below the current directory to the archive ARCHIVE.HPK:
HPACK A -RPDA ARCHIVE
Example: To add all text files in the directory A:/DATA to archive ARCHIVE.HPK, adding error recovery information for each file:
HPACK -E ARCHIVE A:/DATA/*.TXT
Example: To extract the same files from the archive, making use of the error recovery information:
HPACK X -E ARCHIVE *.TXT
Example: To add all files in the current directory to the archive ARCHIVE.HPK, prompting for each file before adding it:
HPACK A -I ARCHIVE *
If all files are moved out of an archive (leaving an empty archive), HPACK will delete the archive as well.
Example: To move all text files from the archive ARCHIVE.HPK into the current directory:
HPACK X -F ARCHIVE *.TXT
Example: To create the archive ARCHIVE.HPK on drive A:, overwriting it if it already exists, and add all files in the current directory to it:
HPACK A -K A:ARCHIVE
When searching for the key corresponding to a given userID, HPACK will perform a case-insensitive match of the given userID against any part of the keys userID. This means that only a partial userID need be given on the command line, and HPACK will use the first key for which the partial userID matches. This makes specifying the userID easier since the entire ID need not be given, but also means care should be taken if there are several similar userID's (all of which may match a certain userID fragment) in a collection of keys.
If there is a chance that the userID is ambiguous, the key can also be specified by its keyID using the standard C programming language format for hexadecimal values namely a prefix of '0x' and then the value itself. The keyID is the 6-digit hexadecimal value displayed for the key. As with userID's, HPACK will perform a case-insensitive match against any part of the full keyID.
If the secret key is protected by encryption, HPACK will prompt:
Please enter password for secret key (8..80 characters)
If an incorrect password is given, HPACK will warn:
Password is incorrect.
and allow the password to be reentered. Up to three attempts at the password are allowed before HPACK gives up.
The security options are as follows:
5
-l<userID>
Secure the entire archive with security information from a given userID.
5
-li<userID>
Secure individual files rather than the archive as a whole, with security
information for a given userID. The use of this option is not generally
recommended since the generation of the security information for each file can
consume a considerable amount of time, and since only the files themselves are
secured it leaves the file attributes and directory information open to
modification. It is however useful when only a few files need to be secured,
the rest being subject to constant change which makes securing them
impractical.
Example: To create the archive ARCHIVE.HPK, add all files in the current directory to it, and secure it on behalf of your cat:
HPACK A -LTHECAT ARCHIVE
Example: To fully back up hard drive C: onto drive A:
HPACK A -KMARDA A:ARCHIVE C:/*
This will create the archive ARCHIVE.HPK on one or more disks in drive A: containing the complete contents of the drive C: (the options used are [-k]ill existing archive, [-m]ultipart archive, store file and directory [-a]ttributes, [-r]ecurse through all subdirectories, for [-d]irectories store [a]ll of them, even empty ones). Once each disk has been completely filled, HPACK will prompt:
Please insert the next disk and press a key
followed by the message:
Continuing...
as it continues the archive on the next disk inserted. Note the use of the [-k]ill existing archive option to overwrite any existing archive of the same name which may already exist on the disk - if HPACK finds an archive of the given name already on the disk and the [-k]ill option is not specified, it will not, by default, overwrite it but will exit with an error message.
Multipart archives have a minimum size of around 500 bytes (roughly the size of a disk sector for many disk formats - storing archive parts of less than 500-odd bytes would be pointless). If a section of a multi-part archive is less than approximately 500 bytes HPACK will skip it and move it to the next (hopefully less full) disk after printing the following warning:
Warning: Archive section too short, skipping...
If a multipart archive is small enough to fit onto a single disk, HPACK will store the archive as a standard archive instead of a multipart one.
Example: To view the files in the previously created multipart archive:
HPACK V A:ARCHIVE
HPACK will automatically determine whether the archive is a multipart archive or not so the [-m]ultipart command is only necessary when creating the archive. Since HPACK stores its directory information at the end of the archive, only the last disk or disks of the archive must be read to obtain the archive directory. Initially HPACK will prompt:
Please insert the disk containing the last part of this archive and
2
press a key.
If the wrong disk is inserted, HPACK will prompt:
This is part <n> of a multipart archive.
Please insert the disk containing the last part of this archive and
2
press a key.
where <n> is the part number of this section of the archive.
Example: To extract the single file LETTER.TXT from the previously created archive:
HPACK X A:ARCHIVE LETTER.TXT
HPACK will then prompt for the disk which contains the file LETTER.TXT:
Please insert the disk containing part <n> of this
2
a key.
where <n> is the part number of the archive section which contains LETTER.TXT.
Example: To fully restore the contents of a hard drive from the previously created archive:
HPACK X -ARDA A:ARCHIVE
HPACK will prompt for the last part of the archive as usual and then for each disk in turn as it extracts the files from the archive.
5
-oa
Automatically overwrite [A]ll existing files on extraction.
5
-on
Automatically overwrite [N]one of the existing files on extraction.
5
-os
[S]mart overwrite. HPACK will change the extension of the file to be extracted
to "000", and try to extract this file. If a file of this name already
exists, the extension will be changed to "001" and so on until it is possible
to extract the file. This option is very useful for files that have been
archived on a system which allows filenames which are longer or more complex
than those allowed by the local system and which due to the filename being
truncated or translated end up with identical names. Note that the term
"extension" can mean different things to different operating systems - HPACK
will do its best to use the local equivalent.
5
-op
[P]rompt for new filename. HPACK will ask for a new filename and try to use
that name, repeating until a non-conflicting filename is given.
Example: To extract all files from the archive ARCHIVE.HPK to the current directory, skipping any files that already exist:
HPACK X -ON ARCHIVE
Example: To add all files in all directories in and below the current directory to the archive ARCHIVE.HPK:
HPACK A -R ARCHIVE *
Example: To add all files in the current directory to all archives in the current directory, without printing the usual progress reports to the screen:
HPACK A -S *
Example: To all all files in /USR/SPOOL/NEWS/COMP/COMPRESSION to the archive COMPRESS.HPK using the unified compression mode:
HPACK A -U COMPRESS /USR/SPOOL/NEWS/COMP/COMPRESSION/*
5
-vf
Display only matching files.
5
-vd
Display only matching directories.
5
-vs
Sort files. Normally files are displayed in the order in which they are stored
within the archive. Using this option will sort the files by name before
displaying them.
Example: To print all the files, but not any directories or subdirectories, in the archive ARCHIVE.HPK:
HPACK V -VF ARCHIVE.HPK
5
-w
Plain text comment. This can be entered in free-form since HPACK will
automatically word wrap the text to fit the screen size. Plain text comments
may also contain formatting commands which control the way the text is
displayed. For more information on formatting the text comments, see the
extended documentation file HPACKEXT.DOC.
5
-wa
ANSI text comment. This type of comment can contain the extended 8-bit
character set used by IBM PC's, as well as ANSI escape codes. No reformatting
of any type is done on ANSI comments. Note that the plain text comment type is
preferred, since many systems cannot display the extended ANSI character set or
interpret ANSI escape codes. Also note that if an ANSI comment is stored as
plain text HPACK will quietly delete all extended characters and ANSI escape
codes when it displays the comment, to make it conform to the 7-bit ASCII
character set.
5
-wg
GIF format graphics comment. Display of this comment format is generally only
suported on systems running graphics-based user interfaces.
Example: To view all comment-type files in the archive ARCHIVE.HPK as files instead of displaying them as comments:
HPACK V -W ARCHIVE.HPK
5
-x
Smart translate. HPACK will attempt to translate all files it recognises as
text files from the textfile format used on the system the file was archived
on to the textfile format used on the system the file is being extracted on.
In most cases this option will be the only one necessary.
5
-xr
Treat carriage return (ASCII 13) as end-of-line marker. The Macintosh stores
text this way.
5
-xl
Treat linefeed (ASCII 10) as end-of-line marker. Text on the Amiga, the
Archimedes, and UNIX systems is stored in this manner.
5
-xc
Treat carriage return/linefeed pairs as end-of-line marker. The Atari ST, MSDOS
and OS/2 store text files like this.
5
-xxnn
Treat the one- or two-character hexadecimal value 'n' or 'nn' as the character
to use as the end-of-line delimiter. For example when moving textfiles from a
QNX 2.x/3.x system (which uses the RS character, ASCII 30 or 1E hexadecimal),
the option would be -xx1e.
5
-xe
Translate the character set from EBCDIC to ASCII. Text on IBM systems is
stored this way.
5
-xp
Translate the character encoding from that used on Prime systems to ASCII.
5
-xa
Translate from ASCII to ASCII.
The textfile translation works by first translating entire character sets (either ASCII, Prime ASCII or EBCDIC) if necessary, and then translating the end-of-line characters, depending on the options specified.
The end-of-line translation options are only available where they would make sense (for example the ability to translate linefeed to linefeed isn't particularly useful). The possible translation options are shown below, with LF being the linefeed character, CR being carriage return, and CRLF being carriage return/linefeed pairs:
To | Atari ST Amiga
| MSDOS Archimedes Macintosh
From | OS/2 Unix
----------+-----------------------------------------------
Atari ST |
MSDOS | [-xc] [-xc]
OS/2 | --- CRLF -> LF CRLF -> CR
|
Amiga |
Archimedes| [-xl] [-xl]
Unix | LF -> CRLF --- LF -> CR
|
| [-xr] [-xr]
Macintosh | CR -> CRLF CR -> LF ---
|
Example: To extract all files with the extension .TXT from the archive ARCHIVE.HPK, translating linefeed characters into whatever end-of-line character the local system uses:
HPACK X -XL ARCHIVE *.TXT
Example: To extract all files with the extension .TXT from the archive ARCHIVE.HPK, translating the files from EBCDIC to ASCII, and translating all carriage return characters to the end-of-line character used by the local system:
HPACK X -XEXR ARCHIVE *.TXT
7
-zinvert
Archimedes version only. ADFS doesn't support extensions to filenames since
dots are used as directory delimiters, which can lead to problems when moving,
for example, source code files ending with the traditional .c and .h to the
Archimedes. Many programs allow a workaround where the file foo.c is accessed
as c.foo. This option allows this form of inversion of the filename/directory
structure so that *.c and *.h would be extracted as c.* and h.*. This command
usually invokes an intense sense of disbelief in non-Archimedes owners.
Incidentally, non-Archimedes owners may wonder what the Archimedes uses in
place of a '.' in filenames. It uses a '/', of course.
<Not yet implemented - will be implemented when HPACK-internal mkdir() and mv()
calls exist>
7
-zlower
Amiga, Archimedes, OS/2, Macintosh, and Unix versions only. Force all file and
directory names to lowercase. Some systems store file and directory names in
uppercase only. Using this option all names will be converted to lowercase
before any operations (such as [V]iew archive, [X]tract from archive, and so
on), are performed on them. When processing Atari ST, MSDOS, and some OS/2
archives, the use of the [-zlower] option is recommended.
7
-znoumask
Unix version only. Normally the setting of the umask environment variable
affects the attribute bits of any files and directories HPACK creates. This
option overrides the umask setting and uses the attributes stored within the
archive. Since these attributes can be set to allow outsiders read/write
access to files and directories which would normally be off-limits to them,
this option should be used with care.
7
-zrsx
VMS version only. Normally VMS files can have 39 characters of filename and 39
characters of extension, or type. This can lead to strange-looking filenames
when they are truncated from operating systems which allow longer or more
flexible names. Using this option truncates filenames to an RSX-11 compatible
format, which results in more traditional-looking names with 9 characters of
filename and three characters of file type, and directory names with 9
characters of filename.
7
-zs
MSDOS version only. Check all files for [s]afe extraction. MSDOS has a
serious problem in that when a file with the same name as a device driver is
extracted (for example 'CON', 'COM1', or 'LPT1') it will force the contents of
that file into the device driver. The damage can be minor for devices like
scramble the CMOS ram, or cause the system to hang - even the changing of
system dates can cause problems on a system running a computer bulletin board
which relies on correct timestamps), all the way through to very serious for
devices like 'SMARTAAR' (it will corrupt the disk cache and therefore corrupt
the drives being cached).
The [s]afe option will check each file before extracting it, and if it corresponds to a device driver will print the warning:
File corresponds to device driver - skipping
and move on to the next file. The only way in which HPACK will allow a file of this type to be extracted is by using the [-o]verwrite [p]rompt option, in which you will be prompted for a new filename to extract under. Even [-o]verwrite [s]mart is unsafe since the peculiar handling of device drivers by DOS makes the automatic substitution of a new filename very difficult.
Filenames which can cause these problems are virtually unheard-of - they would
have to be created deliberately by a malicious user, in which case there are
few limits on the potential damage they can cause.
7
-ztype<type-association>
Archimedes, Apple IIgs, and Macintosh versions only. Some operating systems
store file type information for each file. HPACK will, when extracting files,
try to determine the type information for each file and set it correctly.
However in some cases no type information can be determined, or the determined
information may be incorrect. This option can be used to set type information
for a file, or to override HPACK's internal type-determining rules.
Type information is given as a type-association, associating a file extension with whatever type information the OS requires, and is given in the form:
.<extension>=<type info>{,<type info>}
For example to associate the Macintosh ThinkC source file type with the extension ".c", the type argument would be "TEXT,KAHL", corresponding to the ThinkC file type and creator type.
Example: To associate the ".c" extension on the Macintosh with the ThinkC source file type:
-ztype.c=TEXT,KAHL
Example: To associate the ".gif" extension on the Archimedes with the GIF file type:
-ztype.gif=693
The types given above are actually already part of HPACK's default rule set for type associations, but can be overridden with the use of the [-ztype] option if desired.
Whenever HPACK encounters a filename beginning with an '@' character it treats the rest of the filename as a file containing a list of files to process combined with commands which control the operation of HPACK. Script files have the following format:
Warning: Unknown script command
A sample script is:
# Sample script file
# Save latest work
/users/peterg/hpack/src/*.c
/users/peterg/hpack/src/*.h
/users/peterg/hpack/src/asm/*.asm
# Save correspondence
/usr/spool/mail/p*
Note that the script files themselves are not subject to being overridden by the base path specified with the [-b]ase path option (see "HPACK Options" above). However filenames given within the script file will be overridden by the base path.
Example: To freshen the archive ARCHIVE.HPK with all the files in the files matching SCRIPT* as well as MAIL.TXT and COMPMAIL.TXT:
HPACK F ARCHIVE MAIL.TXT @SCRIPT* COMPMAIL.TXT
HPACK checks the integrity of files stored within an archive by encoding a continuous checksum as part of each file when it is archived, and decoding it as the file is extracted. As soon as an error is encountered, HPACK will skip over the rest of the file and move on to the next one. If the file checksums differ then it may be reasonably assumed that there is an error in the extracted data. This is important: The entire physical universe, including HPACK itself, may one day collapse back into an infinitely small space. Should another universe subsequently re-emerge, the integrity of HPACK archives in that universe cannot be guaranteed.
HPACK also checksums the archive directory. If an error is found in the directory information, the message:
Warning: Archive directory corrupted. Continue (y/n)
will be displayed. Hitting 'N' at this point will abort any attempts to process the archive, hitting 'Y' will process the (damaged) archive. HPACK will attempt some error recovery in this case (for example files and directories which seem to be in impossible directories will be moved into the root directory), and some files may be able to be recovered. If error recovery information (specified with the [-e]rror recovery option (see "HPACK Options" above)) is present, chances of recovering data from an archive with a corrupted directory are greatly enhanced.
Data authentication facilities in an archiver should provide the following features:
HPACK includes provisions for authenticating archived data by adding a unique digital signature to either entire archives or individual files within an archive. This works exactly like a normal signature on a piece of paper, proving that the sender was the true originator of the file or archive. Forgery of a digital signature of this sort is computationally infeasible, and once the data has been signed the sender cannot later disavow his or her signature. In addition a cryptographic checksum of the data or archive is made and included as part of the signature to allow detection of any attempts to tamper with the data. Like forging a signature, defeating the checksum is computationally infeasible.
When the data in an archive with authentication information present is extracted or tested, an authentication check is performed for the entire archive before it is processed. Similarly, an authentication check is performed on files before they are extracted if there is authentication information present.
In order for the authenticity information generation and checking to be possible, two key files are required. To secure archives, the file SECRING.PGP, which contains the secret key of the person securing the archive, is required. To check secured archives, the file PUBRING.PGP, which contains the public key of the person or organization who signed the file or archive is needed. These key files are generated and managed by version 2.0 or higher of Philip Zimmermanns excellent PGP encryption package. If you don't have a copy of PGP, it is recommended you obtain one. PGP is freely available on many archive sites, computer bulletin boards and other systems. PGP is also required to handle any key management, and for authentication of the keys themselves. The PGP documentation and portions of the extended HPACK documentation HPACKEXT.DOC are recommended reading for those wanting more information on the background of PGP and the security techniques used by PGP and HPACK.
If PEM (Privacy-Enhanced Mail) ever becomes a reality, HPACK will support PEM/PKCS format keys as well as PGP ones. This will allow data to be encrypted and decrypted inside the US with PEM keys and outside the US with PGP keys, allowing, for the first time, the easy transfer of public-key encrypted data to and from the US.
Before HPACK can use it, the secret keyring SECRING.PGP must have a small amount of extta information added to it. Details on this are given in the section "Using PGP Secret Keyrings" below.
Like PGP, HPACK will either search for the key files in the current directory or use the environment variable PGPPATH to look for the file. The PGPPATH variable should contain the path to the PUBRING.PGP and SECRING.PGP files, so for example if they were in the directory /BIN/PGP, then PGPPATH should be set with:
35
set PGPPATH=/bin/pgp
(MSDOS, OS/2)
or
35
setenv PGPPATH ~/bin/pgp
(Unix csh)
or
35
PGPPATH=bin/pgp; export PGPPATH
(Unix sh)
If the PGPPATH directory exists and the key files are present in both the current and the PGPPATH directories, the keyring in the PGPPATH directory will be searched first, and if no matching key is found the local keyring will be checked. This means that by default the master keyring is always used, overriding any local keys if necessary.
If the data in the archive, or the archive itself, is to be checked, the authentication check will be performed using the key found in PUBRING.PGP. If the authentication check succeeds, the message:
Good signature from <name>.
Signature made on <date>.
will be displayed, with <name> being the name of the person or organization who made the signature, and <date> being the date the signature was made (on some systems the signature time may be off by a few hours if the system doesn't adjust for different time zones properly). If the check fails, the message:
Warning: Bad signature, doesn't match file contents.
Bad signature from <name>.
Signature made on <date>.
will be printed. If the archive is a multipart archive (for which the authentication check can take some time since an archive stretching over several disks needs to be processed), the message:
Verify multipart archive authenticity [y/n]
is displayed. 'Y' will check the authenticity of the archive, 'N' will skip the authenticity check and continue with processing the archive.
If the data in the archive, or the archive itself, is to be secured, the authentication information will be generated using the key found in SECRING.PGP.
The signature scheme used is the RSA public key cryptosystem (for more information on this and the PGP encryption package see the extended documentation HPACKEXT.DOC). This scheme involves the manipulation of very large numbers, which can be quite time-consuming on slow systems, where the signature generation and checking can take several minutes (for this reason the use of authentication for entire archives rather than individual files in an archive is recommended).
Unlike encryption software, authentication code is not export-restricted from the US. The U.S. Code of Federal Regulations, Title 22 which includes sub-chapter M, "International Traffic in Arms Regulations" (ITAR), makes an exception for software that can only be used for authentication purposes and cannot not be used for general-purpose encipherment and decipherment, as is the case for the data authentication code in HPACK.
HPACK allows data stored in an archive to be encrypted with a variety of public or conventional-key encryption algorithms. Encryption of either entire archives or individual files is possible, as well as the use of multiple keys to encrypt different sections of an archive (though the use of public-key encryption is preferred for this since its inherent automatic key management greatly simplifies handling the encrypted data).
When chosing an encryption key for a conventional-key algorithm, the following guidelines should be observed:
As is the case when using public-key encryption for data/archive authentication, the secret keyring SECRING.PGP will need to have a small quantity of extra information added to it, for which details are given in the section "Using PGP Secret Keyrings" below.
Like PGP, HPACK can store its secret keys in an encrypted format to protect them from prying eyes. However the encryption algorithm HPACK uses is somewhat different to the one use in PGP due to patent restrictions. This means that encrypted PGP keyrings need to have a small amount of extra information added to them before HPACK can use them. The HPACK distribution includes a utility called KEYCVT which performs this task. KEYCVT is run as follows:
KEYCVT <input keyfile> <output keyfile>
The input and output keyfiles are the PGP secret keyring file, and in normal usage would be the same file. KEYCVT will either create a new file to copy the extra information to, or will append it to the existing key file.
The source keyring may contain one or more secret keys. For each key in the file, KEYCVT will display its key information and ask:
Add information for this key so HPACK can use
A "No" response will cause KEYCVT to print:
Skipping key...
and move on to the next key. A "Yes" response will cause KEYCVT to try to add the extra information needed by HPACK. If the key is encrypted, KEYCVT will ask for the decryption password:
Please enter password for this private key
Password:
If the incorrect password is entered, KEYCVT will warn:
Incorrect checksum, possibly due to incorrect password
and allow it to be reentered. Up to three attempts at the password are allowed before KEYCVT gives up. When the key has been read in, KEYCVT will add the extra information encrypted with the same password as was used for the decryption. This is the password which HPACK, like PGP, will use to decrypt the secret key.
Finally, when KEYCVT has finished processing the key file, it will ask:
Finished processing keys. Add new key information to output
A "Yes" response will add the new key information to the output key file. If no keys were converted or a "No" response is given, KEYCVT will display:
No keys converted, output file left unchanged.
and exit.
There have been several occasions in the past when fake versions of new archivers have been distributed. Sometimes these fake release are even wrapped up in a nice-looking "security envelope" guaranteeing their authenticity. Since the source code is freely available, it's all too easy for anyone to create a fake version of HPACK in which the encryption or authentication code has been compromised. In order to avoid any problems in this respect, the distributed HPACK executables are accompanied by a digital signature (see the section "HPACK Archive/Data Authentication" above) which can be used to verify that it is indeed an official version. Unlike the schemes used by other archivers, it is computationally infeasible to compromise this method of authentication.
In order to check the authenticity of the particular version of HPACK, you will need the PGP encryption package (see the section "HPACK Archive/Data Authentication" above), and my public key, which is included in the standard PGP distribution and also in the HPACK distribution. My key is signed by Philip Zimmerman, the inventor of PGP, and several members of the PGP development team. First, you should check my key for authenticity:
pgp -kc Peter Gutmann
When it performs the key check, PGP should display the following signatures:
Type bits/keyID Date User ID pub 1024/997D47 1992/08/02 Peter Gutmann <pgut1@cs.aukuni.ac.nz> sig! E722D9 1992/11/26 Branko Lankester <lankeste@fwi.uva.nl> sig! 997D47 1992/10/11 Peter Gutmann <pgut1@cs.aukuni.ac.nz> sig! 7C02F9 1992/09/07 Felipe Rodriquez <nonsenso@utopia.hacktic.nl> sig! 1336F5 1992/09/05 Harry Bush <Harry@castle.riga.lv> sig! 67F70B 1992/09/02 Philip R. Zimmermann <prz@sage.cgd.ucar.edu>
Version 2.1 and up of PGP can, in addition, calculate a key fingerprint for a key. This can be calculated with:
pgp -kvc Peter Gutmann
PGP should display the following:
pub 1024/997D47 1992/08/02 Peter Gutmann <pgut1@cs.aukuni.ac.nz>
Key fingerprint = 7C 6D 81 DF F2 62 0F 4A 67 0E 86 50 99 7E A6 B1
If the keyID or key fingerprint for my key differs from the one shown above or
the signatures don't check out, then the key is a probably a fake and shouldn't
be trusted. Assuming the key is in order, the authenticity of the program
itself can be checked with:
pgp <program name> hpack.sig
where hpack.sig is the digital signature included with the program as
distributed. For example to check the authenticity of the Archimedes HPACK
executable type:
pgp hpack hpack.sig
When it performs the check, PGP should display:
Good signature from user Peter Gutmann <pgut1@cs.aukuni.ac.nz>.
Signature made <date of signature>
If PGP reports a bad signature then the executable shouldn't be trusted. A
new, hopefully untouched, version can be obtained from any archive site, BBS,
or system which carries the standard HPACK distribution, or you can arrange to
get it directly from the author.
Many people have helped to get HPACK where it is today, among them (in no particular order):
Ports to different operating systems:
Stuart Woolford did the Unix port.
John Burnell did the OS/2 port.
Jason Williams and Edouard Poor helped with the Archimedes
Nick Little and Peter McGavin helped with the Amiga
Murray Moffatt did the Atari ST port.
Translations:
Peter Sowa did the German translation.
Peter de Vocht did the Dutch translation.
Arrigo Triulzi did the Italian translation.
Peter Gutmann had a go at the Klingon translation.
You can contact me in any of the following ways:
By calling me on +64 9 426-5097 within reasonable hours (10am-12pm NZT).
By Usenet email to either pgut1@cs.aukuni.ac.nz (preferred), or p.gutmann@cs.aukuni.ac.nz, peterg@kcbbs.gen.nz, or peter@nacjack.gen.nz (In rough order of preference)
By Fidonet email to Peter at 3:772/90.0. However this is probably about as reliable a link as using carrier mackerel across the Sahara.
By snail mail to 24 Durness Pl, Orewa, Auckland, New Zealand
By throwing a bottle in the ocean (slightly less reliable than the Fidonet link).
By implanting subliminal messages in the music I listen to.
The error messages given by HPACK are the following:
This program is guaranteed to perform as claimed, excluding any delays caused or enhanced by war, civil commotion, or rioting, whether declared, spontaneous, reprehensible, or justified; undue pressure to perform, from whatsoever source; mal de mer, mal de pays, mal de siecle, mal de code, mal de machine, or any force majeure not pretofore invoked.
The program warranty is void in case of nuclear war, whether caused by the program or not.
Amiga is a trademark of Commodore Business Machines. Archimedes is a trademark of Acorn Computers. GIF is a trademark of Compuserve Inc. IBM is a trademark of International Business Machines Corp. Macintosh is a trademark of Apple Computer Inc. MSDOS is a trademark of Microsoft Inc. OS/2 is a trademark of International Business Machines Corp. PKZIP is a trademark of PKWare Inc. Prime and Primos are a trademark's of Prime Computer Corp. QNX is a trademark of <someone>. Rolemaster is a trademark of Iron Crown Enterprises Inc. StuffIt is a trademark of Raymond Lau and Aladdin Systems. ThinkC is a trademark of Symantec Corporation. UNIX is both a trademark and a footnote of AT&T. Windoze is not a trademark of Microsoft Corp. Windows is, but it's a somewhat less accurate description of its performance. These trademark lists are a trademark of too many lawyers and too few people with common sense being involved.