From: amiganer@lisa.cpr.sub.org (Christian-Peter Weiss)
Newsgroups: comp.sys.amiga.applications
Subject: XFH-Handler README
Date: 10 Sep 92 14:28:16 GMT
Reply-To: amiganer@lisa.cpr.sub.org
X-Newsreader: Arn V1.00 beta rel2

The README file distributed with the XFH-Handler for more information

cu Christian

-------------------------------------------------------------------------------


                  Xpk File System Handler v1.12

                      By Kristian Nielsen


This package may be distributed freely for non-commercial purposes along
with Xpk or on its own, provided that all files and subdirectories are
left intact. However, all rights remain with the author. And as usual,
the author will in no way be held responsible for any damage, directly,
implicit or otherwise, resulting from the use of this program. After
all, you get this program for free; use it or not as you like, and at
your own risk. 

This is version 1.12 of the XFH handler, distributed as part of the Xpk
package. XFH is a file system handler like Ram: with the purpose of
making the use of the Xpk compression libraries completely transparent
for everyday use. Specifically, XFH can be set up to mirror a directory
(or a whole disk) so that files can be accessed as normal through XFH:
with the difference that any files that are compressed with Xpk (or
PowerPacker) will be uncompressed fully automatic. Optionally, XFH can
also be instructed to automatically compress files as they are written
using any compression method that Xpk supports. So one use could be to
finally have full access to your powerpacked 'Manuals:' directory and
saving yourself the trouble to pull out powerpacker every time you want
to add another file to the directory. Another more extreme usage would
be to keep a whole partition compressed to save HD space. Whatever way
XFH is used, you are free to mix compressed and 'normal' files; XFH will
ensure that all files will appear as normal to application programs.

By doing this in the framework of a true DOS device handler, a very
flexible and completely system- friendly solution is possible, avoiding
any nasty 'patches' that has been the basis of earlier programs like
PPPatch, though the current version of XFH may seem somewhat less
efficient than these patches.  V1.12 works with Kickstart 1.2/1.3,
though I would strongly recommend using it with 2.0.  Later versions are
likely to be 2.0-only. 

Since this is an early release of the Xpk/XFH combination, a word of 
warning is in order. First of all, please read the doc file ('XFH.doc', 
which should be supplied along with this file) before using the XFH on any 
large scale. It tries to anticipate some of the problems that can result 
from working with packed files as though they were never compressed. In 
particular, the same peculiarities that apply to the RAM: handler should 
be expected with the XFH: ; however, at least with version 1.12 other 
strange behavior can be expected as well. Second, I would like to stress 
again very clearly that I as the author of XFH can in no way be held
responsible for unreliable operation of the handler, nor would it be fair
to see such unreliable operation as signifying that the concepts of the
Xpk and of (de)-compressing file system handlers in general are in any
way flawed (I for one believe these concepts to signify a new era in the
area of data-compressing program interfaces). Having said this, however,
it should also be said that I have myself been using the XFH: extensively
for several months without problems, and that I have never (as yet) lost
a single file of data due to bugs in the Xpk or XFH. And, needless to say,
every effort has been made to make XFH reliable and useful.

Another thing worth pointing out is that XFH is by no means an easy
program to use or even to get running at all. A thorough knowledge of
the Amiga is probably essential or at least recommendable in order to
use this program to its fullest. I'm working with Nicola Salmoria to
make a future version of XFH require less effort to install and run. 
However, due to various reasons (among which is the fact that I no
longer have the equipment to continue the development of XFH or the
money to spend on new equipment), I cannot say when the next XFH release
will be, or indeed whether there will ever be one. Still, I would very
much welcome any critisism, suggestions, bug reports, general experience
etc. from users of this program. If you wish to get in touch with me
you can contact me at this address:

      Kristian Nielsen
      Groenjordskollegiet
      room 6111
      Groenjordsvej
      DK-2300 Koebenhavn S
      Denmark.


Or, if you have access to e-mail, I can be reached as:

      bombadil@diku.dk


                              --- O ---


If you want to have a quick play-around with the XFH before reading the
doc file, follow the instructions below:

 - Make sure xpkmaster.library is accessible in LIBS:, that XFH-Handler
is situated in L: and that the mountlist supplied with the XFH is appended
to the mountlist in DEVS: (and no, don't pack them using Xpk/XFH!).

 - If you already have a directory containing files packed with Xpk (or
powerpacker), you can assign XFH0: to it. For example,

      Assign XFH0: SYS:Text/Manuals

with 'SYS:Text/Manuals' containing some packed files (perhaps in
subdirectories).  This will set up the XFH unit 'XH0:'.  Alternatively,
if you want to experiment with the automatic compression facility of
XFH, you can copy the directory 's/xfh/' to 'S:xfh/' to set up the XFH
unit 'XH1:' for compressing using the BLZW method in RAM: (you will need
the library file 'libs:compressors/xpkBLZW.library').  Note that XFH
needs the path "S:xfh/.xfhrc_?"; the 'xfh/' directory MUST exists in S:
and contain the nessesary files in order to make XFH automatically
compress files.  If you are using KS2.0 and S: is set up as a
multi-assign you must also make sure that the 'xfh/' directory is placed
in the FIRST of the directories that S: is assigned to (usually 'SYS:s'). 

 - Issue the CLI/Shell command

      Mount XH0:
or
      Mount XH1:

depending on whether you used the XFH0: assign or the S:xfh/ option files. 
This will mount the handler, making it ready for use. 

 - Now access the handler in any usual way. For example:

      CD XH0:
      Search fish/#?.doc "Screen hack"
      Protect fish/#?.doc -w
      Lharc -r a ram:mans.lzh XH0:#?

etc. for XH0:, or

      Copy SYS:System/#? XH1:
      List XH1:
      List RAM:
      List SYS:System               ; To compare file sizes

for XH1:. You can play around with other compression methods or directories
by editing the '.xfhrc_?' files in 'S:xfh/' and mounting the corresponding 
XFH unit. The three supplied examples are for a BLZW compressing handler 
in RAM: (unit 1), a BLZW compressing handler in SYS: (unit 2), and an 
encrypting handler in RAM: (unit 3).



                              --- O ---


Program history:

V1.00   Initial release.
V1.00a  Bug in XObjExamine() fixed (it sometimes got the name of the root
        dir wrong). Thanks to Matthias Scheler for reporting this bug.
V1.00b  XFH: now obtains the values returned by ACTION_INFO and
        ACTION_DISK_INFO from the underlying file system. This should
        help problems with 'zero size file system' as experienced with
        earlier versions of MFR for example. Thanks to Keith H. Brown
        for pointing my attention to this problem.
V1.10   Beta version implementing option files and automatic compression.
V1.11   Xpk password support.
V1.12   New XPKPRIORITY option. Also fixes bugs with bad volume names and a 
        msgport that was unnessesarely public; thanks to Nicola Salmoria 
        for telling me about these problem. 

-------------------------------------------------------------------------------
--
     //
    //         UseNet / UUCP: amiganer@lisa.cpr.sub.org
\\ //   InfoServer Friedberg: amiganer
 \X/ Real: Christian-Peter Weiss, Leipziger Str. 15, 6392 Neu-Anspach 1
Newsgroups: comp.sys.amiga.applications