			     BFFS 1.5  (BETA)
	    An AmigaDOS device to read UNIX filesystems
	     	   () 1991 - 1996 by Chris Hooper


*** This guide is NOT complete and has not been thoroughly updated for
    enhancements made since BFFS 1.3.  Page and line numbers have not
    been recomputed.

			 U S E R   M A N U A L


		      Documentation Index
Section       Line #   Page #   Description
------------------------------------------------
Index            9        1	This index
Introduction    29        2	Preliminary Information
Compatibility   62        3	Other systems with which BFFS is compatible
MountList      111        4	Building a MountList entry
HDToolBox      139        5	Using HDToolBox to mount your partitions
Utilities      220        7	Programs to maintain and modify filesystems
Quick Setup    309        9	Steps for experts to get running quickly
Credits        327       10     Who helped with this project
Known Bugs     353       11     Known problems which still exist with BFFS
Appendix A:    371       12	MountList.BFFS information
Appendix B:    446       14	Implementation Information
Appendix C:    502       15	The BSD 4.2 File System
Appendix D:    562       17	Differences between BFFS and the standard FFS
Appendix F:    599       18     Information useful to programmers
Appendix F:    651       19     Troubleshooting Suggestions


INTRODUCTION:

    First, a definition is in order.  The major portion of this
product consists of a piece of software which implements a disk
filesystem.  A filesystem is simply a way of organizing multiple
data files within the confines of a logical device.  Without a
filesystem, that device would appear as nothing more than a single
large file.  In order to store more than one file on a device, it
is necessary to assert some organization in order to be able to
locate and size the separate files. This is what a filesystem
attempts to do.

    BFFS Stands for Berkeley Fast FileSystem, a reimplementation of
the UNIX filesystem, as described in the 1983 CSRG paper, "A Fast
File System for UNIX."  In the last ten years, the Berkeley Fast
Filesystem has become the predominant disk organizer for most UNIX
implementations.  Although there have been subtle changes made by
various vendors since the original, the basic idea and organization
of the filesystem has not changed.  If you would like more details,
please see APPENDIX B for implementation information or consult the
CSRG paper mentioned above.  Please note that Linux currently does
not support the Berkeley Fast Filesystem.

This package contains an implementation of the Berkeley Fast
Filesystem for AmigaDOS 2.04 and higher.  The utility of a
package such is this is that one may seamlessly use the same
logical media while running AmigaDOS as one would use running
UNIX.  It can also be used for data migration.  For instance,
you can write a floppy on a UNIX machine at work (or school),
then use the file stored on that disk directly on your machine
at home.  This packages does not allow you to execute the
applications intended for other platforms on your Amiga.

COMPATIBILITY:

The BFFS filesystem attempts to attain compatibility with the
Berkeley 4.2 BSD filesystem.  Since other UNIX (and compatible)
producers base their system's filesystem on the BSD 4.2 FFS,
this product may be useful with filesystems created by those
other systems.  The tested filesystem types follow:
    SunOS 4.1 and 4.1.1
	BFFS should be highly compatible with this release
	of the BSD filesystem, as BFFS was created against it.
	In order to write a floppy, you need to do the following:
	   1. Make sure you have a floppy drive on the Sun
	   2. Format the floppy
		I recommend "fdformat -lv"
	   3. Create a filesystem on the floppy
		I recommend "newfs -i 16384 -c 80 -t 2 -m 0 /dev/rfd0c"
		as this seems to give the best capacity
	   4. Mount the floppy on a directory (you MUST be root)
		ie: "mount /dev/fd0c /mnt"
	   5. Copy your files to the floppy
	   6. Unmount the floppy
		ie: "umount /dev/fd0c"
    SunOS 4.1.2 (Solaris 1.0.1) and SunOS 4.1.3
	BFFS should be able to at least read filesystems created
	with this OS.  I have done quite a few read and write tests.
	BFFS did not corrupt the filesystem, as far as I could tell.
    Amiga UNIX (SVR4)
	Did minimal testing, but read/write seems stable.
    BSD 4.3 filesystems
	The previous version of BFFS came with newfs and fsck ports
	from BSD 4.3.  It was created and distributed before the
	BSD 4.4 filesystem came into existence, which may explain
	why it happily trashed newer BSD 4.4 filesystems.  This version
	is still compatible with BSD 4.3 filesystems, but...
    BSD 4.4 filesystems
	BFFS can now autodetect BSD 4.3 and BSD 4.4 filesystems and
	knows how to deal with the differing structures in each.
	newfs and fsck included in this distribution are now ports
	of the Berkeley utilities dated 20-Jul-94 and 8-Jun-94
	respectively.  fsck has been used extensively throughout the
	testing process of BFFS.  Since the above filesystems (with
	some exceptions) seem compliant to fsck, I would assume that
	BSD 4.3 and BSD 4.4 FFS should not have a problem reading
	BFFS-written and writing filesystems.

    x86 NOTE:  Use the BFFSFilesystem.ir to read x86 BSD filesystems.
	It automatically handles the swapped byte orders of these
	filesystems, but it read-only for now, as I have no way to
	validate correctness of the filesystem on writes.

    See Appendix A for information on selecting an Amiga device driver
    and appropriate filesystem handler.

BUILDING A MOUNTLIST ENTRY:

    I suggest you use the sample MountList entry (MountList.BFFS) as a
prototype for creating your own MountList entry.  You can find line-by-line
documentation in the MountList.BFFS file.  For the generic case, it should
be (at most) necessary to check the following MountList fields:
    FileSystem, Device, Unit, BlocksPerTrack, Surfaces, LowCyl, and HighCyl

    You can add this new MountList entry to your system's MountList
(Devs:MountList) or put it in a separate file.  If you kept the same device
name as the example MountList, you would type:
	Mount BFFS: from MountList.BFFS
    Say you chose instead to call your BFFS partition BSDA and add it to
your Devs:MountList.  In that case, you would type:
	Mount BSDA:

    If you are mounting a filesystem which already has a UNIX BSD file
system on it, then you should be able to CD to that device, just like any
other AmigaDOS file system device.  If you want to create a new BFFS
file system, you must first use newfs before BFFS can access it.  Do the
newfs command after you have mounted the partition.

    Once you have the filesystem working, you might try tweaking some of
the following fields:
    Mount, Priority, Buffers, Reserved, and PreAlloc

Please see Appendix A for descriptions of the MountList fields.

USING HDTOOLBOX TO AUTOMATICALLY MOUNT YOUR PARTITIONS:

    Before you follow the below procedure, I recommend you first
try mounting the filesystem using a MountList entry.  A filesystem
compatibility problem before the machine even boots could be a
major headache!  If this happens to you, see Appendix F.

    If you are using a hard disk, you most likely already have a
partition set aside for the UNIX filesystem.  If not, you need to
first set up the disk and partition using HDToolBox.  Consult your
AmigaDOS manual for help.

    Get into HDToolBox and select "Partition Drive."  Choose the
partition you want to make a BFFS partition, then select the
"Advanced Options" button.  Pick the "Change File System for
Partition" button.

    If this is an Amiga UNIX partition, then the File System type
is probably "Reserved Partition."  Otherwise, the most likely case
is "Fast File System."  Be careful in your selections!  If you
didn't watch what you were doing, you might have accidentally
picked a partition with AmigaDOS data you wanted to keep.  If the
File System Type is "Custom File System," make especially sure
you know what's going on there.  If you're at all unsure, click
the "Cancel" button and start over.

    Select the "Custom File System" button and fill in the
"Identifier =" field.  I recommend the value 0x42464653 ('BFFS'),
but you can use and filesystem type you want.  The NetBSD people
are partial to 'BSDx' - where x would be 'R', 'S', 'D', 'E', 'F',
'G', 'H', etc depending on how NetBSD is using the partition.
The disadvantage to this scheme is that for every UNIQUE file
system Identifier you want to mount as a BFFS filesystem, you
have to add the BFFS filesystem to the RDB with that Identifier.

    "Use custom boot code?" should be set to "No, " unless it is
required by NetBSD to boot (not currently).

    Set the "beginning:" and "end:" fields as you would if those
were the "Reserved" and "PreAlloc" fields of the MountList.  Then,
Click on the "Ok" button.

    Click on the "Add/Update File Systems" button.  This screen
allows you to update the RDB on the disk with the new version of
BFFS. Every time you assign a different Identifier to one of your
partitions, you need to "Add New File System" with that same
Identifier.

    Click on the "Add New File System" button now.  Change the
"Enter Filename of File System" to point to the file where you
have the new BFFSFileSystem.  Change the "DosType for File System"
to be the same as you entered as the Identifier for the Custom
File System. The "Version" of the filesystem does not matter.
Click on "Ok" when you are done.  Then click "Ok" on the "File
Systems" screen.

    If you have more partitions to add as BFFS filesystems, do
those in the same manner as above.  Note that if you use the same
Identifier for all filesystems, you do not need to "Add New File
System" more than once.  This is not an option for NetBSD users.

    When done, Click "Ok" on the "Partitioning Drive" screen.  Then
Click on "Save Changes to Drive."  After that operation is complete,
you will need to reboot for the machine to mount the filesystem.

    The Reserved and PreAlloc fields of a MountList entry may be changed
in HDToolBox by clicking on "Partition Drive."  From there, you need to
select the partition by clicking on the appropriate partition in the bar
graph.  Select the "Advanced Options" button, then the "Change File
System for Partition" button.  The Reserved field is "beginning" under
"Reserved blocks at."  The PreAlloc field is "end" under "Reserved
blocks at."

** SPECIAL NOTE **
    The PreAlloc and Reserved fields are treated as unsigned longwords
by HDToolBox.  They are specified as signed longwords when using the
MountList.  This basically means that when you want to specify a value
such as -1 in HDToolBox, you must use 4GB - value.  Thus, 4GB - 1 =
4294967295.  To tell the filesystem not to attempt to read a disk
label, put 4294967295 in the box "reserved blocks at the beginning."

MAINTENANCE UTILITIES

    There are several support programs included in this distribution
of the BFFS system package.  These programs were very helpful during
the development of the BFFSFileSystem and will hopefully be just as
useful to you.  I intend to offer just an overview of the function
of those programs here.  Read the documentation file associated with
the utility if you need more information.

o  BFFSTool
	This program is used to both monitor and modify the
	operation of a running BFFS filesystem.  You are able to
	change filesystem buffers, modify the write sync timers,
	clear statistics, and change operating flags (auto symlink,
	ignore case, dir comments, unix paths. and read only).

o  dcp
	Dcp is a program that can copy to/from devices and files.
	You can specify either the physical device and partition
	or the AmigaDOS device.  This program was originally
	distributed separately.  It is a replacement for the
	filetodev and devtofile programs distributed in version 1.1
	of BFFS.  This is the latest version of dcp and is included
	here mainly for completeness.

o  echmod
	Change file (user / group / other) permissions

o  echown
	Change ownership (user id / group id) of a file per the
	AmigaDOS 3.0 packet.

o  edumpfs
	Most users will probably never need to use this program.
	It prints out information on the disk label and superblock,
	as organized by newfs and modified by the filesystem.

o  eln
	This program can create a hard or soft link using the BFFS
	filesystem.  I wrote it because I couldn't get MakeLink
	under AmigaDOS 2.04 to create soft links.  Command line
	syntax is identical to the Unix command of the same name,
	except this version can accept multiple names which will
	point to a single destination.

o  els
	Quick and (not so dirty anymore) directory lister showing
	extended AmigaDOS 3.0 permissions and file owner/group.  Can
	also show true UNIX permissions, file size in blocks, and file
	inode number on a UNIX filesystem.    

o  etouch
	Command to set file time(s) command for BFFS filesystems,
	with SYSV syntax.
o  rdb
	Edit the rdb area of most manufacturers' disk devices.
	This is a crude command-line program, but can do most things
	HDToolBox can do (and a few it can't).  I wrote it because
	my IVS Trumpcard wouldn't talk to HDToolBox and I wanted to
	have more than *one* automount partition.
	
o  mknod
	Create Unix device nodes (block and character special)
	using a mouned BFFS filesystem.  This program uses a new
	packet assigned by Randell Jesup (ACTION_CREATE_OBJECT),
	which may be used to create an arbitrary file type.

o  fsck
	This program will check your filesystem for inconsistencies.
	It is a port of the 4.4 BSD program of the same name.  One
	item you should note.  This program doesn't seem to like
	SunOS filesystems as well as it does BSD filesystems.  If
	fsck tells you the disk requires a label for a SunOS disk,
	supply the location of the superblock: "fsck -b 16 DEVICE:"
	Otherwise, you should be able to just type: "fsck DEVICE:"
	See the manual page for more information.

o  newfs
	This program will create a new filesystem on top of the
	specified device.  If diskpart was not first run on the
	partition, the size of the entire partition will be used
	for the filesystem.  Warning: This program unmercifully
	writes over an existing filesystem if you specify the
	wrong device.  This is a port of the 4.4 BSD program of
	the same name.  See the manual page for more information.

o  diskpart
	This program will let you assign multiple BSD partitions
	within a single AmigaDOS partition.  WARNING:  These
	partitions are not compatible with the way NetBSD partitions
	were implemented on the Amiga.  This /might/ change in the
	future.  This program is a port of the 4.4 BSD program of the
	same name.  See the manual page for more information.

o  restore
	This program will restore a BSD format dump file to a
	BFFS filesystem.  It is a port of the BSD 4.4 restore
	command. Creation of most UNIX special files are supported.
	The corresponding dump program has not been ported.




QUICK SETUP

For those with previous experience with setting up this (or other)
AmigaDOS filesystems, here are the things you need to do:

o   Copy BFFSFilesystem to L:
o   Create a MountList entry for the filesystem.  You must specify:
	FileSystem, Device, Flags, StackSize, Priority, Globvec,
	LowCyl, HighCyl, Surfaces, BlocksPerTrack, Buffers,
	Reserved, Prealloc, and DosType.  If you have any questions,
	please consult the sample MountList.BFFS file (in APPENDIX A)
	or the section on building a MountList entry.
o   Mount the filesystem
o   If all went well, you should be able to CD to the filesystem,
	as you've named in the MountList.  If all did not go well,
	hopefully your Amiga did not crash.  Consult the Appendices
	to ensure you've configured everything correctly.

CREDITS

    Ken Dyke           Assembly Author (stack and diskchange), always
                       the quickest reference for my needs!!  :)
    Dominic Giampaolo  Beta Tester, if it's a bug, he's seen it
    Bill Moore         Original DOS interface Author, program concept
    Arthur Hoffmann    Beta Tester, no matter how stable, he'll find
    Chris Hooper       Main Author, program concept and design
                       some problem.  :)
    Randell Jesup      Gave AmigaDOS filesystem insight, helpful hits,
                       and new packets throughout!
    Thomas Kroener     Beta Tester, tried quite a few combinations
    Tero Manninen      Beta Tester, the fastest enforcer hit finder,
                       and has been helping out since BFFS 1.2!!
    Ty Sarna           Beta Tester, not only does he find bugs, he
                       also suggests cool improvements!
    Stefan Sticht      Beta Tester, found hits in 1.25
    Lutz Vieweg        Beta Tester, reported many fixable bugs and
                       submitted HD_Raw_Sun_Floppy_Label


Please remember that this software is freeware and these people
have volunteered their time for this package to become a reality.
Everyone above deserves pat on the back for making our lives on
the Amiga a little nicer.

KNOWN BUGS

There are a few problems which still remain with the current
implementation of BFFS.  Some are:

Disk volume nodes aren't fully supported.  This mainly affects
removable media.  Basically, if you intend on removing the disk,
make SURE there are no AmigaDOS locks on that volume.



APPENDIX A:  MountList.BFFS information
    FileSystem entry has to change if you don't put BFFSFileSystem in l:
    Device depends on the device in which your filesystem resides:
	For 2090 controllers, use hddisk.device.
	For 2091 controllers, use scsi.device.
	For IVS controllers, use IVS_SCSI.device.
	For filesystems in a file, use fmsdisk.device () Matt Dillon.
	For floppies, use newer mfm.device from Commodore (Consultron)
		    [ or messydisk.device from MessyDOS () ]
    Unit entry changes depending on device.
	Quick notes:
	    IVS SCSI addresses begin at 1, not 0
	    2090(A) SCSI addresses begin at 3; MFM is at 1 and 2
    Mount entry should be set to your preference, with 0 meaning mount
	at first access and 1 meaning mount immediately.
    StackSize should be left at 1024.  It must be at least 600 bytes.
    Priority should be left at 5.  Should you have a need to change it,
	the filesystem will not really care.
    GlobVec should be left at -1.
    LowCyl should be set to the beginning cylinder of the filesystem.
	For Sun-formatted disks, this is best set at 0.
	For AmigaDOS disks with Amiga partitions and Unix partitions,
	    set this to the starting cylinder number for the partition.
	    If you do not know this, you should be able to find this
	    out using HDToolBox.  Look at the starting cylinder for
	    the partition under advanced options.
    HighCyl should be set to the ending cylinder of the filesystem.
	It is used to determine the maximum block which may be read
	from or written to within the filesystem.  Failure to set
	this parameter correctly may result in symptoms such as the
	filesystem not being read, the machine crashing, or data
	loss in other disk partitions.
    Surfaces should be set per your drive's geometry [number of heads].
	This information may be acquired from HDToolBox.
    BlocksPerTrack should be set per your drive's geometry [may be
	specified as sectors per track]. This information may be
	acquired from HDToolBox.
    Buffers should be set to the number of 512-byte blocks of system
	memory you want to devote to the cache.  A minimum of six is
	required for proper operation of the filesystem.

    Reserved is the Unix partition on the media you want to access.
	It can also specify that no disk label is present:
        -1 = no disk label
	 0 = access first partition
	 1 = access second partition
	 2 = access third partition
	 3 = access fourth partition
	 4 = access fifth partition
	 5 = access sixth partition
	 6 = access seventh partition
	 7 = access eighth partition
	 8 = do not scan for a Sun disk label
	16 = do not scan for a BSD disk label
	** You may combine the 8 or 16 with 0-7
	   to achieve a combination of parameters.
    PreAlloc is used to modify the startup defaults for the filesystem
	 1 = Turn on automatic symlink resolution
	 2 = Turn on case independence.  If you are familiar with the
	     Amiga filesystem, you probably want to turn this on.
	 4 = Make filesystem respect UNIX paths and not AmigaDOS paths
	 8 = Turn on directory comments (symlink destinations)
	16 = Turn on directory comments (inode, perms, user, grp, etc)
	32 = Invert the definition of the other/group permission bits
	64 = Report space free relative to minfree (instead of actual)
	Bits 8-15 represent a signed byte which is the GMT offset for
	    the filesystem when dealing with file times.  I recommended
	    you use BFFSTool to get the settings you want, then put the
	    PreAlloc number it gives you into your MountList.
	You may combine any of the above to alter multiple parameters.
    DosType should be left as 0x42464653 ("BFFS"), unless you have a
	specific need for a different DosType.

APPENDIX B: Implementation Information

    There are a few points where this implementation of the
Berkeley Fast Filesystem differs substantially from the original
product described in the 1983 CSRG paper, "A Fast File System for
UNIX."

    It is recommended you read the above paper before the
following information.  If you do not have that paper, APPENDIX C
provides some quick detail on the BSD 4.2 Fast File System.

    Files which have been opened and written to at least once are
automatically extended in allocation to the size of an entire
filesystem block.  When the file is closed, if it only requires
allocation within the direct blocks of the inode, it will be
trimmed down to the size specified in the inode.  Fragment blocks
will be moved near others to conserve full filesystem blocks. By
using this system, only full filesystem blocks need be found and
allocated.  This reduces the overhead and complexity of file block
allocation when writing to files.

    This program ignores superblock parameters such as interleave
and maxcontig and always strives to locate the next block
allocation contiguous with the previous disk block allocation.
The read and write routines will then batch up as large a transfer
as possible when requesting data to be read from or written to the
media.  This should improve the transfer rate for large files.

    New files have a preference for the nearest cylinder group
(cg) to that of the parent directory.  New directories are located
in cgs having the most free inodes (and data blocks available).

    Files will continue to grow in the same cylinder group until
all available filesystem blocks have been allocated.  At that
point, the cg with the largest number of available blocks is
chosen to continue allocation.

    It is recommended a BSD 4.2 filesystem be kept at most 90%
full in order for the block layout policies to remain effective.
This is true for the BFFSFileSystem as well.  One thing you might
want to note is that the filesystem requires at least one empty
filesystem block in order to deal with any file allocation.
Because of this, the Info command is only told the number of
complete filesystem blocks which are still available on the disk.
So, you might find that creating a small may not induce an
apparent increase in disk utilization.  In that case, the file was
able to be allocated in a fragment block from the disk.  If you
need to know, BFFSTool can provide the exact information from the
superblock.

    When performing file reads or writes, the filesystem strives
to combine as many contiguous disk fragments together as possible
when a disk transfer is necessary.  The smallest disk transfer
possible will always be the fragment size.  Any read or write
request smaller will be buffered through the cache.

APPENDIX C: The BSD 4.2 File System

    The original AT&T System 7 filesystem organized data on the
disk as follows:
    [  Superblock  |  Inode Area  |  Data Area  ]

    The Superblock describes the parameters which make up the
filesystem.  These include the number of blocks in the file
system, the number of inodes, and a pointer to a list of free
blocks.

    A file is made up of an inode and some number of data blocks
from the data area of the disk.  The inode is the center of
activity in the Berkeley filesystem.  It contains information such
as file block locations, file ownership, access permissions, and
file type.

    The problem with this system comes as the disk got larger and
transfer rates faster.  When accessing a typical file, the inode is
first read, then some data from the file is typically transferred.
The distance between the inode and its data blocks will typically
incur a long seek across the disk.  This seek is time intensive, and
the file data may not be retrieved or written before the disk head
can physically get there.

    The BSD 4.2 Fast File System gets around this problem by
breaking the disk up into smaller chunks called cylinder groups.
Each cylinder group contains an inode area and a data area.  The
idea is to place data related to an inode within the same or near
cylinder group to reduce the disk head movement.  This also tends
to reduce file fragmentation as the disk blocks for the file are
located closer together.

    Another optimization made in the BSD filesystem was the
introduction of filesystem blocks which are made of up smaller
fragment blocks. File blocks are allocated in units of filesystem
blocks, with the remainder allocated to fragment blocks.  This
scheme guarantees to localize filesystem size blocks of file data
together, achieve greater disk throughput by minimizing seek time
and maximizing the transfer block size.

So, a BSD 4.2 filesystem may be organized on the disk as follows:
    [  cg 0  |  cg 1  |  cg 2  |  cg 3  |  ... ...  ]

Where each cg is organized as:
    [  Data Area | Superblock | Inode Area | Data Area  ]

    You may wonder why the inode area is located inside the data
area. The reason is another goal in the development of the Berkeley
FFS.  To improve disaster recoverability.  You will notice the
superblock is replicated for every cylinder group on the disk.  The
first cg contains the only working superblock, the others contain a
static copy of the superblock, which are not usually referenced
after filesystem creation.  The cylinder group metadata (inode area
and superblock) float to a different fixed location inside each
cylinder group. This reduces the possibility that a single head or
cylinder loss could jeopardize all data on the disk.

    The above additions make for a much more complex implementation,
consuming fast CPU time in place of slow disk time.

APPENDIX D: Differences between BFFS and the standard Amiga FFS

    When executing directory listings, you should notice less disk
head movement with BFFS than with the Amiga FFS.  This is mainly due
to the required localization of inodes.  What will typically happen is:
    A seek to read the directory inode if it is not already cached
    A seek to read the directory's filenames and inode numbers
    Multiple seeks in the inode area to read file inodes
** Up to 72 inodes can be stored in a single cylinder of a floppy

    You will notice that that most "list" programs show soft links
as directories.  This is a fault of the list program and not the
filesystem.  Currently, most applications do not work correctly with
soft links.  Hopefully more will work correctly in the future (OS 3.0).

    Permissions for files are as expected.  Except that Write permission
and Delete permission appear identical.  The real permissions are not
identical, however. As of BFFS 1.5, the permissions set in the parent
directory of a file determine whether it may be deleted.  Write permission
is as expected. OS 3.0 extended information is supported for a file's
group and other permissions, though only the owner permissions are
respected for file access.

  The Execute bit will determine if a directory may be accessed.
     The Read bit may in the future determine if the entries in a
		directory are visible.
    The Write bit will determine if files may be created in the directory.

    Directory comments are used to BFFS to provide additional
information about the file listing.  BFFS does not allow the user to
change the directory comments like the Amiga FFS does.  These informational
comments must be enabled using BFFStool (or via a MountList entry).  There
are two types of comments (which may be combined).  The first is symlink
and char/block device information.  The second is the inode information not
presented by the OS 2.0 FileInfoBlock.

APPENDIX E: Information useful to programmers

BFFS supports the following packets (ACTIONs):
	IS_FILESYSTEM		LOCATE_OBJECT		EXAMINE_OBJECT
	READ			WRITE			EXAMINE_NEXT
	FINDINPUT		FINDOUTPUT		FINDUPDATE
	END			FREE_LOCK		SEEK
	DELETE_OBJECT		RENAME_OBJECT		RENAME_DISK
	CREATE_DIR		COPY_DIR		PARENT
	DISK_INFO		SAME_LOCK		SET_PROTECT
	INFO			WRITE_PROTECT		MORE_CACHE
	DISK_CHANGE		INHIBIT			FLUSH
	DIE			CURRENT_VOLUME		MAKE_LINK
				EXAMINE_FH

	SET_OWNER		SEEK			READ_LINK
	EX_OBJECT		EX_NEXT			SET_DATE
	GET_DISK_FSSM		FREE_DISK_FSSM
	

I intend on (eventually) supporting:
	SET_FILE_SIZE					COPY_DIR_FH
				FH_FROM_LOCK		ADD_NOTIFY
	PARENT_FH		EXAMINE_ALL		REMOVE_NOTIFY


The FORMAT packet is implemented by newfs, a separate program.
The TIMER packet is used internally to know when to sync fs data.


Sending the filesystem an ACTION_DIE will put the filesystem in a
quiescent state and deallocate all dynamic memory.  Querying system
statistics (ie: by using BFFSTool) will reactivate the filesystem.
I've ran into problems with messydisk.device supporting the
TD_REMCHANGEINT packet correctly.  Because of this, the filesystem
will look for this name and substitute trackdisk.device for the
disk change information.  I've also had a problem with the older
version of mfm.device (2.0).  Apparently it cannot handle reading
a chunk of data across a cylinder boundary.  I know this is fixed
in version 40.9, and most likely earlier versions as well.

There is an additional packet type the filesystem supports:
ACTION_FS_STATS (value 2999, unofficial) is used by BFFSTool to
get a pointer to the statistics data structures.  Once BFFSTool
has that pointer, it has immediate access to many of
BFFSFileSystem's internal variables.

BFFS supports some additional EntryTypes in the FileInfoBlock of
Examined file locks.  Specifically:
	ST_BDEVICE   -10          ST_LIFO      -13
	ST_CDEVICE   -11          ST_FIFO      -14
	ST_SOCKET    -12	  ST_WHITEOUT  -15

Per the AmigaDOS 3.0 extensions to the FileInfoBlock, OwnerID
and GroupID, as well as the group and other permissions are now
available in the FileInfoBlock.

Packets implemented in addition to above:
	ACTION_CREATE_OBJECT   2346	(published packet)
	ACTION_SET_DATES       2998	(unofficial)
	ACTION_SET_TIMES       2997	(unofficial)
	ACTION_SET_PERMS       2996	(unofficial)
	ACTION_GET_PERMS       2995	(unofficial)

APPENDIX F: Troubleshooting Suggestions

Situation:  You went against my advice of testing with a MountList
	    entry first and now you are whimpering, your head on the
	    keyboard, the machine at a "Software Failure".  In other
	    words, The machine crashes on boot, with no escape.
Suggestion: Pull out a gun...no...  Well, obviously, you don't want
	    the machine to try to automount the disk.  Your hard
	    drive controller may have a jumper that you can pull or
	    set to disable autoboot.  If so, do this.  If not, you
	    might try unplugging your drive from the bus on powerup,
	    then back in after the machine has booted (off floppy,
	    or if you're lucky another drive).  Then use your handy
	    dandy disk partitioner thing (HDToolBox for Commodore
	    controllers) to remove that partition.  If that doesn't
	    work, you might try using my rdb editor to manually
	    remove the entry for that partition from the RDB.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Situation: The machine does not read any BFFS floppies and you are
	   using mfm.device.  It seems to (almost) work, as the drive
	   grinds back and forth several times before giving you an
	   error (when you set Reserved=0 in MountList).

Possible Problem: You are using an old version of mfm.device.  Get
	   a newer version.  I know version 40.9 works ok.

Possible Problem: The floppy has an incompatible superblock.  If it's
	   a 386BSD floppy (or any other floppy written with an Intel
	   processor), make sure you use the BFFSFileSystem.i handler.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Situation: The floppy is not accessed at all, and you get nothing
	   when you try to access bf0:

Possible Problem: The filesystem handler does not exist where the
	   MountList tells AmigaDOS to find it.  The example
	   MountList.BFFS requires BFFSFileSystem be put in L:

Possible Problem: The device specified in the MountList does not
	   exist in the expected location.  If no path is specified,
	   AmigaDOS checks the Devs: directory.

Possible Problem: The wrong Unit was specified in the MountList.
	   This can actually cause a lot of programs to crash
	   unexpectedly for some reason.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Situation: Filesystem GURUs when disk is changed

Possible Problem: You're using an older version of messydisk.device
		  which doesn't support disk change ints correctly.
		  Upgrade messydisk or get the new mfm.device from
		  Consultron or Commodore.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Situation: Filesystem GURUs at some seemingly random point.

Suggestion: Drop some email to cdh@mtu.edu describing your
	    problem and what I can do to duplicate it.  If I can't
	    duplicate it (or find it relatively easy), it's not in
	    there.  ;)

Solution: Disassemble; fix; reassemble yourself.  :)
