Imported Upstream version 1.1.11upstream/1.1.11upstream

21 files changed, 1608 insertions, 0 deletions

diff --git a/doc/genisoimage/README b/doc/genisoimage/README
new file mode 100644
index 0000000..708bae5
--- /dev/null
+++ b/doc/genisoimage/README
@@ -0,0 +1,26 @@
+Cdrkit carries a fork of the mkisofs program called genisoimage.
+
+The acompanying documentation consists of the manual page genisoimage.8 and
+README files found in the following locations (shell globing used):
+
+doc/:
+
+README.multi: documentation and examples for creating
+  multi-session CDs and DVDs
+
+README.cdplus: documentation and examples for creating
+  CD-plus (aka CD-extra) disks
+
+doc/genisoimage:
+
+README.releasenotes: release notes for old mkisofs releases
+
+README.*boot: documentation for various boot loader related
+  extensions for different architectures
+
+README.hfs*: hints and usage for HFS related features
+
+README.*: additional docs for special features
+
+Eduard Bloch -- Mon, 11 Sep 2006 23:05:29 +0200
+
diff --git a/doc/genisoimage/README.alphaboot b/doc/genisoimage/README.alphaboot
new file mode 100644
index 0000000..4bd10e1
--- /dev/null
+++ b/doc/genisoimage/README.alphaboot
@@ -0,0 +1,28 @@
+# README.alphaboot    Steve McIntyre <steve@einval.com> 2004/07/19
+
+The alpha boot support allows you to create a bootable CD which will
+work with DEC/Compaq/HP Alpha machines, for example bootable
+installation media.
+
+The method used for this is the same as in aboot, the bootloader for
+Linux on Alpha, and works with SRM firmware. See the SRM Firmware
+HOWTO at http://www.alphalinux.org/faq/SRM-HOWTO/ for more details
+about SRM.
+
+In common with many Unix systems, the SRM code reads the first
+512-byte "sector" off a disk and parses information in that
+sector. The information in question is the location (start "sector")
+and length of the first stage boot loader. On a Linux system, this
+file will normally be called bootlx.
+
+SRM will load and execute the first stage boot loader, and from that
+point the system should be able to find the normal OS kernel and start
+up fully.
+
+To use the Alpha boot support code in genisoimage, simply specify the
+location of the first stage boot loader (relative to the CD root)
+using the -alpha-boot command line switch:
+
+genisoimage ... -alpha-boot boot/bootlx -o alpha.iso files
+
+
diff --git a/doc/genisoimage/README.compression b/doc/genisoimage/README.compression
new file mode 100644
index 0000000..4c8d425
--- /dev/null
+++ b/doc/genisoimage/README.compression
@@ -0,0 +1,17 @@
+Transparent decompression (-z option) is available on Linux kernels
+using kernel version 2.4.14 or 2.4.9-ac14 or later.
+
+You also need the zisofs-tools package, containing the mkzftree
+utility, to create the compressed files; this package is available at:
+
+ftp://ftp.kernel.org/pub/linux/utils/fs/zisofs/
+
+The mkzftree utility can also be used to read compressed CD-ROMs on
+systems which do not support transparent decompression.
+
+The use of a separate utility allows compression to be controlled on a
+per-file basis.  A file which is not compressed can be read on any
+system.
+
+Transparent decompression is implemented as an extension to Rock
+Ridge, so Rock Ridge needs to be enabled (-R or -r options.)
diff --git a/doc/genisoimage/README.eltorito b/doc/genisoimage/README.eltorito
new file mode 100644
index 0000000..5c94cdc
--- /dev/null
+++ b/doc/genisoimage/README.eltorito
@@ -0,0 +1,101 @@
+
+What is El Torito?
+------------------
+Simply put, El Torito is a specification that says how a cdrom should
+be formatted such that you can directly boot from it.
+
+The "El Torito" spec says that ANY cdrom drive should work (scsi/eide)
+as long as the BIOS supports El Torito. So far this has only been
+tested with EIDE drives because none of the scsi controllers that has
+been tested so far appears to support El Torito. The motherboard
+definately has to support El Torito. The ones that do let you choose
+booting from HD, Floppy, Network or CDROM.
+
+How To Make Bootable CDs
+------------------------
+
+For the x86 platform, many BIOS's have begun to support bootable CDs.
+The standard my patches for genisoimage is based on is called "El Torito".
+
+The "El Torito" standard works by making the CD drive appear, through BIOS
+calls, to be a normal floppy drive. This way you simply put an floppy
+size image (exactly 1440k for a 1.44 meg floppy) somewhere in the
+iso fs. In the headers of the iso fs you place a pointer to this image.
+The BIOS will then grab this image from the CD and for all purposes it
+acts as if it were booting from the floppy drive. This allows a working
+LILO boot disk, for example, to simply be used as is.
+
+It is simple then to make a bootable CD. First create a file, say "boot.img"
+which is an exact image of the boot floppu currently in use. There is
+at least one HOWTO on making bootable floppies. If you have a bootable
+floppy handy, you can make a boot image with the command
+
+dd if=/dev/fd0 of=boot.img bs=10k count=144
+
+assuming the floppy is in the A: drive.
+
+Place this image somewhere in the hierarchy which will be the source
+for the iso9660 filesystem. It is a good idea to put all boot related
+files in their own directory ("boot/" under the root of the iso9660 fs,
+for example), but this is not necessary.
+
+One caveat - Your boot floppy MUST load any initial ramdisk via LILO,
+not the kernel ramdisk driver! This is because once the linux kernel
+starts up, the BIOS emulation of the CD as a floppy disk is circumvented
+and will fail miserably. LILO will load the initial ramdisk using BIOS
+disk calls, so the emulation works as designed.
+
+The "El Torito" specification requires a "boot catalog" to be created as 
+ll.
+This is a 2048 byte file which is of no interest except it is required.
+My patches to genisoimage will cause it to automatically create the
+boot catalog. You must specify where the boot catalog will go in the
+iso9660 filesystem. Usually it is a good idea to put it the same place
+as the boot image, and a name like "boot.catalog" seems appropriate.
+
+
+So we have our boot image in the file "boot.image", and we are going to
+put it in the directory "boot/" under the root of the iso9660 filesystem.
+We will have the boot catalog go in the same directory with the name
+"boot.catalog". The command to create the iso9660 fs in the file
+bootcd.iso is then
+
+genisoimage -b boot/boot.img -c boot/boot.catalog -o bootcd.iso .
+
+The -b option specifies the boot image to be used (note the path is
+relative to the root of the iso9660 disc), and the -c option is
+for the boot catalog file.
+
+Now burn the CD and its ready to boot!
+
+CAVEATS
+-------
+
+I don't think this will work with multisession CDs.
+
+If your bootable floppy image needs to access the boot floppy, it has
+to do so through BIOS calls. This is because if your O/S tries to talk to
+the floppy directly it will bypass the "floppy emulation" the El Torito spec
+creates through BIOS. For example, under Linux it is possible to
+have an initial RAM disk loaded when the kernel starts up. If you let the
+kernel try to read in the initial RAM disk from floppy, it will fail
+miserably because Linux is not using BIOS calls to access the floppy drive.
+Instead of seeing the floppy image on the CD, Linux will be looking at
+the actually floppy drive.
+
+The solution is to have the initial boot loader, called LILO, load your
+initial RAM disk for you.  LILO uses BIOS calls entirely for these
+operations, so it can grab it from the emulated floppy image.
+
+I don't think making a CD bootable renders it unreadable by non-El Torito
+machines. The El Torito spec uses parts of the iso9660 filesystem which
+were reserved for future use, so no existing code should care what it does.
+
+Genisoimage currently stores identification records in the iso9660 filesystem
+saying that the system is a x86 system. The El Torito spec also allows
+one to write PowerPC or Mac id's instead. If you look at the code in write.c
+you could figure out how to change what is written.
+
+/* @(#)README.eltorito	1.2 00/03/18 eric */
+/* Edited for name change by Eduard Bloch, mkisofs -> genisoimage */
+
diff --git a/doc/genisoimage/README.graft_dirs b/doc/genisoimage/README.graft_dirs
new file mode 100644
index 0000000..da05e29
--- /dev/null
+++ b/doc/genisoimage/README.graft_dirs
@@ -0,0 +1,151 @@
+This is from "Eduardo M. A. M. Mendes" <mendes@mgconecta.com.br>
+
+Creating multi-session CD's with dir=/ feature Micro Howto
+
+This mini-howto was written as guide to help me to create multi-session CD's
+with the possibility of determining the location of files. I hope
+that this guide helps you too.
+
+In order to use wodim it is first necessary to define to which scsi bus
+the cd-writer is connected. In my case the setup is dev=0,3,0. It is also
+interesting to have a separate directory in which all image files can
+be dumped: /home/cdsource is the directory I chose for dumping the images.
+
+The best way to understand how to create multi-session cds is to read
+README.multi. Most of what is going to be said here is based on that
+README file and on the help of several wodim users. 
+
+This Micro Howto is divided into two parts as follows:
+
+Example a) A dir/=/dir1/dir2 example
+
+Example b) A dir1/dir2/=/dir3/dir4 and dir1/dir2a=/dir5/dir6 example
+
+
+We are now ready to start.
+
+Example a) An dir/=/dir1/dir2 example
+
+A simple example will demonstrate that we can create multi-session cds 
+with the dir_feature of the type dir/=/dir1/dir2
+
+Objetive: Saving root directories of Redhat 6.1 and Col 2.3 on a single CD.
+
+Observation: Redhat installation is mounted on COL 2.3 at /mnt/redhat
+
+First image - RedHat 6.1 - /mnt/redhat/root
+
+genisoimage -D -l -r -f -m core -L -o image1.raw redhat/=/mnt/redhat/root
+
+This will create a redhat directory on the cd. The option -D should be
+used with care. The other options used in the above command are just 
+to demonstrate the use of genisoimage.  Please
+refer to man genisoimage if you want to know more.
+
+
+To see if the image is created as expected, we need to mount image1.raw using
+the option -o loop (Linux only! for information on Solaris read README.verify)
+as follows:
+
+mount -t iso9660 image1.raw /mnt/image -o loop
+
+To see the contents type:
+
+ls -l /mnt/image/redhat
+
+Does it look ok?  Great! Unmount /mnt/image. Now the burning process itself:
+
+wodim -v -dev=0,3,0 -multi -eject image1.raw 
+
+To check the burned image we need to mount the cd; something like
+
+mount -t iso9660 /dev/scd0 /mnt/cdroms
+
+/mnt/cdroms is the device file for the cdrom I use.
+
+
+Second image - Caldera 2.3 - /root
+
+
+To create the second image on our cd, we need get information
+about sectors related to the first track. To do that, issue the command
+
+wodim -v -dev=0,3,0 -msinfo 
+
+wodim returns the following number
+
+0,135563
+
+This number is the format XX,YY discussed on README.multi.  XX would be used
+for testing the images as well as burning the new track.
+
+genisoimage -D -l -r -f -m core -L -C 0,135563 -M /dev/scd0 -o image2.raw  caldera/=/root
+
+Now we need to check of image2.raw is ok. The following command creates exactly what we 
+need.  Plese note that -C option. Only the first number changes in this case. The second one
+is always zero.  In our case the first number is zero due to wodim -msinfo.  When 
+more tracks are added to the cd this number will change.
+
+genisoimage -D -l -r -f -m core -L -C 0,0 -M /dev/scd0 -o image2_test.raw  caldera/=/root
+
+mount -t iso9660 image2_test.raw /mnt/image -o loop
+
+ls -l /mnt/image shows that there are two directories: redhat and caldera, just the way
+we wanted.
+
+Now let us burn image2.raw (not image2_test.raw)
+
+wodim -v -dev=0,3,0 -multi -eject image2.raw
+
+We can mount the CD again to see that the two directories are there.  We can carry on
+doing this until we decide to close the CD. If this is the case, don't use -multi when
+burning the last session.
+
+b) A dir1/dir2/=/dir3/dir4 and dir1/dir2a=/dir5/dir6 example
+
+The above example seems a bit silly, one could argue. Why did I create a single directory
+called root and within two sub-directories: redhat and caldera?  
+
+Using the procedure described above we would do as follows:
+
+genisoimage -D -l -r -f -m core -L -o image1.raw etc/redhat/=/mnt/redhat/etc
+
+wodim -v -dev=0,3,0 -multi -eject image1.raw 
+
+To check the burned image we need to mount the cd; something like
+
+mount -t iso9660 /dev/scd0 /mnt/cdroms
+
+wodim -v -dev0,3,0 -msinfo 
+
+wodim returns the following number
+
+0,14391
+
+The second image can be created using
+
+genisoimage -l -r -f -m core -L -C 0,14391 -M /dev/scd0 -o image2.raw  etc/caldera/=/etc  
+
+Creating a test image2
+
+genisoimage -l -r -f -m core -L -C 0,0 -M /dev/scd0 -o image2_test.raw etc/caldera/=/etc 
+
+mount -t iso9660 image2_test.raw /mnt/image1 -o loop
+
+It works!!   That is great!!!
+
+Now the burning process itself.
+
+wodim -v -dev=0,3,0 -multi -eject image2.raw
+
+and we're done !!!!
+
+To add more tracks just do as indicated above.
+
+Good luxk!!!
+
+Eduardo Mendes - 11/23/99
+
+Source: README.graft_dirs from cdrtools package
+Edited for cdrkit by Christian Fromme <kaner@strace.org> and Eduard Bloch
+
diff --git a/doc/genisoimage/README.hfs_boot b/doc/genisoimage/README.hfs_boot
new file mode 100644
index 0000000..378bb95
--- /dev/null
+++ b/doc/genisoimage/README.hfs_boot
@@ -0,0 +1,76 @@
+Making HFS bootable CDs
+
+*******
+The HFS boot code in genisoimage/mkhybrid is now very out of date ...
+it does not support booting from IDE CDROMS, and probably won't work on
+"newer" Macs.
+
+The HFS boot code will be updated at some point in the future
+*******
+
+It *may* be possible to make the hybrid CD bootable on a Mac. As I do not
+have easy access to a CD-R (nor a Mac) at the moment, I have not actually
+created and written a bootable hybrid to CD - however, I *think* it will work!
+
+A bootable HFS CD requires an Apple CD-ROM (or compatible) driver, a bootable
+HFS partition and the necessary System, Finder, etc. files.
+
+A driver can be obtained from any other Mac bootable CD-ROM using the
+"apple_driver" utility (to make, type "make apple_driver"). This file can
+then be used with the -boot-hfs-file option. See below for usage.
+
+The HFS partition (i.e. the hybrid disk in our case) must contain a
+suitable System Folder, again from another CD-ROM or disk.
+
+For a partition to be bootable, it must have it's "boot block" set. The boot
+block is in the first two blocks of a partition. For a non-bootable partition
+the boot block is full of zeros. Normally, when a System file is copied to
+partition on a Mac disk, the boot block is filled with a number of required
+settings - unfortunately I don't know the full spec for the boot block ...
+
+I'm guessing that this will work OK ...
+
+Therefore, the utility "apple_driver" also extracts the boot block from the
+first HFS partition it finds on the given CD-ROM and this is used for the
+HFS partition created by mkhybrid.
+
+To extract the driver and boot block:
+
+apple_driver CDROM_device > HFS_driver_file
+
+where CDROM_device is the device name used by the CD-ROM (e.g. /dev/cdrom)
+
+The format of the HFS driver file is:
+
+	HFS CD Label Block                              512 bytes
+	Driver Partition Map (for 2048 byte blocks)     512 bytes
+	Driver Partition Map (for 512 byte blocks)      512 bytes
+	Empty                                           512 bytes
+	Driver Partition                                N x 2048 bytes
+	HFS Partition Boot Block                        1024 bytes
+
+The Perl script "hdisk.pl" can be used to give a listing of what's on
+a Mac CD. hdisk.pl is part of hfsutils.
+
+A hybrid CD is made using the option "-boot-hfs-file" e.g.
+
+mkhybrid -boot-hfs-file HFS_driver_file -o hfs.raw src_files/
+
+The -boot-hfs-file implies the -hfs option.
+
+PLEASE NOTE:
+
+By using a driver from an Apple CD and copying Apple software to your CD,
+you become liable to obey Apple Computer, Inc. Software License Agreements.
+
+The driver code (both extracting the driver and creating partitions etc.
+is based on code from "mkisofs 1.05 PLUS" by Andy Polyakov
+<appro@fy.chalmers.se> (see http://fy.chalmers.se/~appro/mkisofs_plus.html)
+
+
+Any comments, bug reports/fixes to the address below
+
+James Pearson (j.pearson@ge.ucl.ac.uk)
+19-Jul-2000
+
+Edited for program name change by Eduard Bloch, 2006
diff --git a/doc/genisoimage/README.hfs_magic b/doc/genisoimage/README.hfs_magic
new file mode 100644
index 0000000..814d59e
--- /dev/null
+++ b/doc/genisoimage/README.hfs_magic
@@ -0,0 +1,69 @@
+
+Find file types by using a modified "magic" file
+
+Based on file v3.22 by Ian F. Darwin (see libfile/LEGAL.NOTICE and
+libfile/README.dist - File v3.22 can be found at many archive sites)
+
+For each entry in the magic file, the "message" for the initial offset MUST
+be 4 characters for the CREATOR and 4 characters for the TYPE - white space is
+optional between them. Any other characters on this line are ignored.
+Continuation lines (starting with a '>') are also ignored i.e. only the initial
+offset lines are used.
+
+e.g magic entry for a GIF file:
+
+# off	type		test		message
+#
+# GIF image
+0       string          GIF8            8BIM GIFf
+>4      string          7a              \b, version 8%s,
+>4      string          9a              \b, version 8%s,
+>6      leshort         >0              %hd x
+>8      leshort         >0              %hd,
+#>10    byte            &0x80           color mapped,
+#>10    byte&0x07       =0x00           2 colors
+#>10    byte&0x07       =0x01           4 colors
+#>10    byte&0x07       =0x02           8 colors
+#>10    byte&0x07       =0x03           16 colors
+#>10    byte&0x07       =0x04           32 colors
+#>10    byte&0x07       =0x05           64 colors
+#>10    byte&0x07       =0x06           128 colors
+#>10    byte&0x07       =0x07           256 colors
+
+Just the "8BIM" "GIFf" will be used whatever the type of GIF file it is.
+The continuation lines are used by the "file" command, but ignored by
+mkhybrid. They could be left out completely.
+
+The complete format of the magic file is given in the magic man page (magic.5).
+
+See the file "magic" for other examples
+
+Use with the -magic magic_file option, where magic_file is a file
+described above.
+
+The magic file can be used with the mapping file (option -map) - the order
+these options appear on the command line is important.  mkhybrid will try to
+detect if the file is one of the Unix/Mac files (e.g. a CAP or Netatalk
+file) first. If that fails, it will then use the magic and/or mapping
+file e.g:
+
+mkhybrid -o output.raw -map mapping -magic magic src_dir
+
+The above will check filename extensions first, if that fails to set the
+CREATOR/TYPE, the magic file will be used. To check the magic file
+before the filename extensions, use:
+
+mkhybrid -o output.raw -magic magic -map mapping src_dir
+
+
+Using just a magic file - filename extensions will not be checked e.g:
+
+mkhybrid -o output.raw -magic magic src_dir
+
+For the magic method to work, each file must be opened and read twice
+(once to find it's CREATOR/TYPE, and a second time to actually copy the
+file to the CD image). Therefore the -magic option may significantly
+increase processing time.
+
+If a file's CREATOR/TYPE is not set via the magic and mapping matches,
+then the file is given the default CREATOR/TYPE.
diff --git a/doc/genisoimage/README.hide b/doc/genisoimage/README.hide
new file mode 100644
index 0000000..ae8521b
--- /dev/null
+++ b/doc/genisoimage/README.hide
@@ -0,0 +1,208 @@
+Hiding files on a CD
+=====================
+
+This document attempts to show how to hide files from being seen by an
+operating system accessing a CD as an ISO9660/Rock Ridge, Joliet or HFS
+CD. It also highlights some of the limitations ...
+
+Note: this document is about the various -hide options - not be confused with
+the -hidden options.
+
+The -hidden options set the 'EXISTENCE' bit in the directory entry which
+means the file or directory will be invisible - unless some special option
+is used to mount or view the CD - Linux has the 'unhide' mount option to
+make these files visible. i.e. the directory entry exists on the CD.
+
+With hindsight, to avoid confusion with the -hidden option, it would have
+been better to chose an option name like '-omit' instead of '-hide'...
+
+The various -hide options actually exclude the relevant directory entry
+from the directory tree. Therefore, it is not possible to access a file
+or directory that has be hidden with the -hide option when the ISO9600/Rock
+Ridge directory is mounted - because the directory entry does not exist on the
+CD (but the file data does). You would probably be able to access this file
+or directory when mounted as a Joliet or HFS CD (depending on other options
+used). Similarly, a directory entry hidden with the -hide-joliet option
+will not be accessible when mounted as an Joliet CD. Similarly for -hide-hfs
+etc.
+
+If you don't want a file or directory to appear on the CD at all, then use the
+-exclude options, not the -hide options (genisoimage completely ignores any
+file/directory excluded with the -exclude options).
+
+
+Using the hide options
+======================
+
+There are 6 hide options:
+
+-hide		   Hide a file/directory from the ISO9660/Rock Ridge directory
+-hide-list	   As above, but read file names from a file
+-hide-joliet	   Hide a file/directory from the Joliet directory
+-hide-joliet-list  As above, but read file names from a file
+-hide-hfs	   Hide a file/directory from the HFS directory
+-hide-hfs-list	   As above, but read file names from a file
+
+You can use the -hide, -hide-joliet and/or -hide-hfs options as many times
+as you like on the command line, but if you have many files to hide, then
+it may be better to put your file names in a file (one per line) and use
+the corresponding 'list' option. You can also use the three -hide-list options
+as many times as you want.
+
+The arguments to the -hide options are either the 'basename' or the 'whole
+path name' of a file. That is, if you use the option:
+
+% genisoimage -hide ABC [-other-options] CD_directory
+
+then any file with the name ABC will be hidden. If you want to be more
+specific, then use the whole name - as seen by genisoimage e.g.:
+
+% genisoimage -hide CD_directory/XYZ/ABC [-other-options] CD_directory
+
+will hide just the file 'CD_directory/XYZ/ABC' - not any other file called
+'ABC' that might exist under 'CD_directory'. However, if your command line
+is like:
+
+% genisoimage -hide CD_directory/XYZ/ABC [-other-options] ./CD_directory
+
+Then the file 'CD_directory/XYZ/ABC' will not be hidden because as far as
+genisoimage is concerned. Its whole path is actually './CD_directory/XYZ/ABC'.
+
+You can use wild cards in the -hide arguments.
+
+If the file name to be hidden is a directory, then the directory and all
+its contents are hidden.
+
+The main use of the hide options is on a multi platform (hybrid CD) to hide
+various files/directories that are operating system specific from been seen
+on the CD when mounted on another OS. i.e. You may want to hide Macintosh
+executables from being seen when the CD is mounted as a Joliet CD on a PC etc.
+
+For example, say we want to create a ISO9660/Rock Ridge, Joliet, HFS hybrid
+CD from files/directories in the directory called 'cd_dir' - which are:
+
+MAC/
+MAC/app
+MAC/data/
+MAC/data/file1
+PC/
+PC/app
+PC/data/
+PC/data/file1
+UNIX/
+UNIX/app
+UNIX/data
+UNIX/data/file1
+COMMON/
+COMMON/some_files
+
+We could use the command line:
+
+% genisoimage -r -J -hfs -hide MAC -hide PC -hide-joliet MAC \
+	-hide-joliet UNIX -hide-hfs PC -hide-hfs UNIX -o cd.iso cd_dir
+
+This will give a CD that when mounted as a Rock Ridge CD, you will only 
+see the directories UNIX and COMMON, as a Joliet CD the directories
+PC and COMMON, and as an HFS CD the directories MAC and COMMON.
+
+If you also had the three files in the current directory called README.hfs,
+README.joliet and README.unix - but you wanted to have each of these
+files appear as just 'README' when mounted, then you could use the above
+command line with the following:
+
+% genisoimage -r -J -hfs -graft-points -hide MAC -hide PC -hide-joliet MAC \
+	-hide-joliet UNIX -hide-hfs PC -hide-hfs UNIX \
+	-hide README.hfs -hide README.joliet -hide-joliet README.hfs \
+	-hide-joliet README.uni -hide-hfs README.joliet -hide-hfs README.unix \
+	README=README.hfs README=README.joliet README=README.unix \
+	-o cd.iso cd_dir
+
+Note: we've used the -graft-points option as we're using the '=' syntax
+to insert the files called README.hfs, README.joliet and README.unix as
+'README'
+
+The resulting CD when mounted as a Rock Ridge CD, will have the directories
+UNIX and COMMON - with the file called README - which was originally 
+called README.unix.
+
+However, in most circumstances, it would be better to have the contents
+of each of the OS specific directories (plus the contents of the COMMON
+directory) to appear at the top level of the CD. i.e. when the CD is mounted
+(as ISO9660/Rock Ridge, Joliet or HFS) it has the contents:
+
+README
+app
+data/file1
+some_files
+
+Unfortunately, this is not as straight forward as it may seem - i.e. doing
+the following may seem OK, but it won't work - for reasons I'll explain 
+later:
+
+It gets a bit messy using the -graft-points syntax above, so we'll assume
+each of the MAC, UNIX and PC directories contain the correct README, We'll
+also change to the 'cd_dir' directory and use the command:
+
+genisoimage -r -J -hfs -hide MAC -hide PC -hide-joliet MAC \
+	-hide-joliet UNIX -hide-hfs PC -hide-hfs UNIX \
+	-o cd.iso MAC PC UNIX COMMON
+
+You will get errors like:
+
+genisoimage: Error: UNIX/README and MAC/README have the same Rock Ridge name
+...
+genisoimage: Unable to sort directory 
+
+This is because you can not hide "pathspecs" that are directories ("pathspecs"
+are file names given on the command line, or in a path-list file). This a 
+"feature" of genisoimage. In this case nothing is actually hidden at all.
+
+So you might think that the following may work:
+
+genisoimage -r -J -hfs -hide "MAC/*" -hide "PC/*" -hide-joliet "MAC/*" \
+	-hide-joliet "UNIX/*" -hide-hfs "PC/*" -hide-hfs "UNIX/*" \
+	-o cd.iso MAC PC UNIX COMMON
+
+which may appear to work - but when the CD is mounted as an ISO9660/Rock Ridge
+or Joliet CD, then the directory "data" is missing.
+
+Again this is a feature of genisoimage - the directories PC/data and UNIX/data
+are mapped by genisoimage to the same output directory called "/data" - the
+various "hide" flags are stored with this directory info - in this case as 
+the output directory "/data" is first hidden from the ISO9660/Rock Ridge and
+then the Joliet directory, the net result is that "/data" gets hidden from
+both directories ... the way genisoimage hides HFS directories is slightly
+different, so in this case the directory "data" exists on the HFS volume
+and contains the correct contents.
+
+However, it is possible to obtain the required result, but we have to be
+careful about hiding multiple input directories that map to a single output
+directory.
+
+To do this we have to hide just the files in these directories (or more
+accurately, all the non-directories). This is best done by using lists of
+files to hide for example: 
+
+find PC -type f -print > pc.list
+find UNIX -type f -print > unix.list
+find MAC -type f -print > mac.list
+
+genisoimage -r -J -hfs -hide-list pc.list -hide-list mac.list \
+	-hide-joliet-list unix.list -hide-joliet-list mac.list \
+	-hide-hfs-list pc.list -hide-hfs-list unix.list \
+	-o cd.iso MAC PC UNIX COMMON
+
+i.e. instead of trying to hide a directory and letting genisoimage hide its
+contents, we explicitly hide all the files in the directory, but not the
+directory and any of its sub-directories.
+
+This will work for the above input files, but if your directory trees contain
+symbolic links and/or directories that will not get merged, then the hide lists
+will have to be tailored to get the required result.
+
+
+James Pearson 22-Nov-2001
+
+Any comments/problems to j.pearson@ge.ucl.ac.uk
+
+Modified for cdrkit/genisoimage by Eduard Bloch, Wed, 27 Dec 2006
diff --git a/doc/genisoimage/README.hppaboot b/doc/genisoimage/README.hppaboot
new file mode 100644
index 0000000..a7a7549
--- /dev/null
+++ b/doc/genisoimage/README.hppaboot
@@ -0,0 +1,38 @@
+# README.hppaboot    Steve McIntyre <steve@einval.com> 2004/07/19
+
+The hppa boot support allows you to create a bootable CD which will
+work with HP PA/RISC machines, for example bootable installation
+media.
+
+The method used for this is the same as in palo, the bootloader for
+Linux on hppa. See the palo README for more details about supported
+hardware etc.
+
+The HPPA firmware reads the first 2048-byte sector off a disk and
+parses information in that sector. The information in question is the
+location (start sector) and length of various files:
+
+ * a 32-bit kernel image
+ * a 64-bit kernel image
+ * first stage bootloader (iplboot)
+ * (optional) ramdisk
+
+and also the system command line to use, e.g.
+
+ "5/vmlinux HOME=/ TERM=linux console=tty"
+
+The firmware will load and execute the first stage boot loader, and
+that should be able to find the (32- or 64-bit) kernel and boot
+normally. Whether you need a 32- or 64-bit kernel depends on your
+hardware; some will even support both.
+
+To use the hppa boot support code in genisoimage, simply specify the boot
+command line and file locations (relative to the CD root) as follows:
+
+genisoimage ... -hppa-cmdline <cmdline, parts separated by spaces or commas> \
+            -hppa-kernel-32  <32-bit kernel> \
+            -hppa-kernel-64  <64-bit kernel> \
+            -hppa-bootloader <bootloader> \
+            -hppa-ramdisk    <ramdisk file> \
+            -o hppa.iso hppa-files
+
diff --git a/doc/genisoimage/README.joliet b/doc/genisoimage/README.joliet
new file mode 100644
index 0000000..ab9bf5d
--- /dev/null
+++ b/doc/genisoimage/README.joliet
@@ -0,0 +1,53 @@
+Some thoughts on Joliet - why it is a dumb idea to have a CD
+with Joliet enhancements but without Rock Ridge.
+It also helps you to understand why it it not possible to append
+a new session to a multi-session Joliet CD when Rock Ridge is
+missing.
+
+-	Joliet is not an accepted independant international standard
+	like ISO-9660 or Rock Ridge (IEEE-P1282).
+	Joliet has been created in 1995 - Rock Ridge in 1990.
+	Rock Ridge became a IEEE standard around 1992.
+
+Joliet is an unjustified addition to ISO-9660.
+
+-	The Joliet tree has no relation to the
+	ISO-9660 tree. Files from the ISO-9660 tree and from the
+	Joliet tree only share content. In general, it is not
+	possible to find the ISO-9660 name from a Joliet name
+	and vice versa if you check both trees on a CD.
+
+	Rock Ridge extensions are located at the end of each
+	ISO-9660 directory record. This makes the Rock Ridge
+	tree closely coupled to the ISO-9660 tree.
+
+-	Joliet does not allow all characters too, so the
+	Joliet filenames are not identical to the filenames
+	on disk.
+
+	As the ISO-9660 tree is the standard reference tree
+	on a CD and the ISO-9660 filenames don't allow all
+	characters and there is a length limitation, the
+	ISO-9660 names cannot be mapped to the filenames on the
+	OS reference tree on disk for doing multi-session.
+
+	Due to different limitations, the short ISO-9660 name 
+	is in most cases not equal to the Joliet name or the
+	Rock Ridge name.
+
+-	Joliet has a filename length limitation of 64 chars (independent
+	from the character coding and type e.g. European vs. Japanese)
+	This is annoying as modern filesystems all allow 255 chars
+	per path name component.
+
+	Joliet uses UTF-16 coding while Rock Ridge uses ISO-8859 or
+	UTF-16 based chars and allows 255 octets. Using UTF-8,
+	Rock Ridge allows 85 Japanese characers or 255 US-ASCII chars.
+
+Other than slightly longer filenames, Joliet offers no new properties
+over plain ISO 9660. Rock Ridge is an open extendable standard and
+there is no filesystem property on Win32 that could not be implemented 
+using Rock Ridge.
+
+Except Linux and FreeBSD, there is no POSIX-like like OS that supports
+Joliet. Never create Joliet only CD's for that reason.
diff --git a/doc/genisoimage/README.macosx b/doc/genisoimage/README.macosx
new file mode 100644
index 0000000..e082bfc
--- /dev/null
+++ b/doc/genisoimage/README.macosx
@@ -0,0 +1,43 @@
+Notes on using the --osx-hfs option when running genisoimage on MacOS X
+
+genisoimage does not use any of the MacOS APIs to access files - it uses
+standard (POSIX style) library calls. Under normal circumstances, all
+genisoimage will 'see' is the data fork of files on an HFS (or HFS+) file system.
+
+However, Apple have provided a way for POSIX style applications to 
+access the resource fork - using the following syntax:
+
+If a file exists on an HFS volume with the name 'foo', then the resource fork
+can be accessed using the file name 'foo/rsrc' or foo/..namedfork/rsrc'
+(the data fork can also be accessed using 'foo/..namedfork/data').
+
+These 'pseudo' file names are not normally visible in a directory - unless
+you access them directly (e.g. 'ls -l */rsrc etc).
+
+To access the finder information, Apple have provided an undocumented library
+function called getattrlist(). Fortunately there are example of its usage
+in the Darwin (MacOS kernel) source code.
+
+
+Although MacOS X can use HFS(+) as its file system, Apple have decided to
+move away from using HFS to store finder info and resource data - for 
+example, the TYPE of a file may be based on its file name extension and the
+TYPE field in the finder info empty.
+
+genisoimage knows nothing about these file name extension mappings, so if the
+--osx-hfs option is used and the source files are on MacOS X HFS(+) volumes,
+by the fact that they are HFS files, they will get identified as 'MacOS X HFS'
+and the resulting file on the output CD image will have empty TYPE and CREATOR
+fields.
+
+Therefore, if the input finderinfo is blank and the the resource fork is
+empty, genisoimage will assume the input file is not a 'real' HFS file - which
+means the TYPE and CREATOR may then be set using the file's magic number or
+genisoimage' file name extension mapping.
+
+The only real benefit of using the --osx-hfs option is when the source files
+are on an OS9 or earlier HFS or HFS+ volume e.g. an existing HFS CD.
+
+James Pearson 3-Jul-2002
+Edited for program name change by Eduard Bloch, 2006
+
diff --git a/doc/genisoimage/README.mipsboot b/doc/genisoimage/README.mipsboot
new file mode 100644
index 0000000..1e5227a
--- /dev/null
+++ b/doc/genisoimage/README.mipsboot
@@ -0,0 +1,26 @@
+# README.mipsboot    Steve McIntyre <steve@einval.com> 2004/07/19
+
+The mips/SGI boot support allows you to create a bootable CD which
+will work with big-endian mips SGI machines, for example bootable
+installation media.
+
+The method used for this is the same as in genisovh, a tool to make
+CDs bootable for Linux on SGI.
+
+The SGI firmware reads the first 512-byte "sector" off a disk and
+parses information from a volume descriptor header in that sector. The
+information in question is the location (start sector) and length of
+bootable kernel images; up to 15 are supported.
+
+The firmware will load and execute kernels listed. (I'm not sure what
+it will do if more than one kernel is listed - it may display a boot
+menu).
+
+To use the SGI boot support code in genisoimage, simply specify the kernel
+file locations (relative to the CD root) as follows:
+
+genisoimage ... -mips-boot <kernel file #1> \
+            ... 
+            -mips-boot <kernel file #n> \
+            -o mips.iso mips-files
+
diff --git a/doc/genisoimage/README.mipselboot b/doc/genisoimage/README.mipselboot
new file mode 100644
index 0000000..af3979b
--- /dev/null
+++ b/doc/genisoimage/README.mipselboot
@@ -0,0 +1,29 @@
+# README.mipselboot    Steve McIntyre <steve@einval.com> 2004/07/19
+
+The mips/DEC boot support allows you to create a bootable CD which
+will work with little-endian mips DEC machines (e.g. older
+DECstations), for example bootable installation media.
+
+The method used for this is the same as in delo, the Linux-on-mipsel
+bootloader. See the delo README for more information about how to
+configure the DECstation's firmware to find and boot the CDROM.
+
+The DEC firmware reads the first 512-byte "sector" off a disk and
+parses information from that sector. The information in question is
+the location (start sector) and length of the first stage boot
+loader.
+
+(On Linux, this boot loader is in ELF format and the firmware does not
+know how to deal with ELF directly, we have to parse the ELF headers
+and find the raw binary data needed inside it. Pointers to the start
+and length of that raw binary are what is stored in the boot sector.)
+
+The firmware will load and execute the first stage boot loader, and
+from that point the system should be able to find the normal OS kernel
+and start up fully.
+
+To use the DEC boot support code in genisoimage, simply specify the kernel
+file location (relative to the CD root) as follows:
+
+genisoimage ... -mipsel-boot <kernel file> -o mipsel.iso mipsel-files
+
diff --git a/doc/genisoimage/README.mkhybrid b/doc/genisoimage/README.mkhybrid
new file mode 100644
index 0000000..49036a1
--- /dev/null
+++ b/doc/genisoimage/README.mkhybrid
@@ -0,0 +1,145 @@
+
+mkhybrid v1.13 has merged with mkisofs which was forked to genisoimage later
+
+HFS hybrid code Copyright (C) James Pearson 1997, 1998, 1999, 2000
+libhfs code Copyright (C) 1996, 1997 Robert Leslie
+libfile code Copyright (c) Ian F. Darwin 1986, 1987, 1989,
+	1990, 1991, 1992, 1994, 1995
+mkisofs code Copyright 1993 Yggdrasil Computing, Incorporated
+
+*** NEWS ***
+
+Macs can now read Joliet CDs - see http://www.tempel.org/joliet/
+
+***
+
+*** IMPORTANT ***
+
+The meaning of some of the HFS command line options has changed since
+version 1.12b5.2. This change is to make the way genisoimage decodes the 
+various Apple/Unix file formats (CAP, AppleDouble, MacBinary etc.) less
+confusing and more logical. To decode one or more of the Apple/Unix files,
+then the corresponding "double dash" option must be given (i.e. --cap, 
+--double, --macbin etc.) genisoimage can search for all known Apple/Unix files
+by using the -probe option.
+
+The options that have changed are:
+
+Option		old meaning			new meaning
+======		===========			===========
+
+-hfs		Create an HFS hybrid CD		Create an HFS hybrid CD.
+		and attempt to decode all	Any Apple/Unix file is only
+		Apple/Unix files (except	decoded if one or more of
+		MacBinary and AppleSingle)	the "double dash" options are
+						given
+
+-apple		Create an ISO9660 with		Create an ISO9660 with
+		Apple extensions CD and		Apple extensions CD. Any
+		attempt to decode all		Apple/Unix file is only decoded
+		Apple/Unix files (except	if one or more of the
+		MacBinary and AppleSingle)	"double dash" options are given
+
+-no-mac-files	Do not attempt to decode	No longer used
+		any Apple/Unix file
+
+-probe		Attempt to decode		Attempt to decode all
+		MacBinary and AppleSingle	Apple/Unix files
+		as well as the other
+		Apple/Unix files
+
+***
+
+Most of the HFS features work fine, however, some are not fully tested.
+These are marked as "Alpha" in the man page.
+
+See "ChangeLog.mkhybrid" for any minor changes/bug fixes
+
+If you are using SunOS 4.1.[34], then you need the following patches
+to read CDs with associated files:
+
+SunOS 4.1.3:		Patch 101832-05
+SunOS 4.1.3_U1:		Patch 101833-02
+SunOS 4.1.4:		Patch 102583-02
+
+
+EXAMPLES
+
+To create a HFS hybrid CD with the Joliet and Rock Ridge extensions of
+the source directory cd_dir:
+
+% genisoimage -o cd.iso -r -J -hfs cd_dir
+
+To create a HFS hybrid CD from the source directory cd_dir that contains
+Netatalk Apple/Unix files:
+
+% genisoimage -o cd.iso --netatalk cd_dir
+
+To create a HFS hybrid CD from the source directory cd_dir, giving all files
+CREATOR and TYPES based on just their filename extensions listed in the file 
+"mapping".:
+
+% genisoimage -o cd.iso -map mapping cd_dir
+
+To create a CD with the 'Apple Extensions to ISO9660', from the source
+direcories cd_dir and another_dir. Files in all the known Apple/Unix format
+are decoded and any other files are given CREATOR and TYPE based on their
+magic number given in the file "magic":
+
+% genisoimage -o cd.iso -apple -magic magic -probe cd_dir another_dir
+
+The following example puts different files on the CD that all have
+the name README, but have different contents when seen as a
+ISO9660/RockRidge, Joliet or HFS CD.
+
+Current directory contains:
+
+% ls -F
+README.hfs     README.joliet  README.unix    cd_dir/
+
+The following command puts the contents of the directory "cd_dir" on the
+CD along with the three README files - but only one will be seen from
+each of the three filesystems:
+
+% genisoimage -o cd.iso -hfs -J -r \
+        -hide README.hfs -hide README.joliet \
+        -hide-joliet README.hfs -hide-joliet README.unix \
+        -hide-hfs README.joliet -hide-hfs README.unix \
+        README=README.hfs README=README.joliet README=README.unix \
+        cd_dir
+
+i.e. the file README.hfs will be seen as README on the HFS CD and the
+other two README files will be hidden. Similarly for the Joliet and
+ISO9660/RockRidge CD.
+
+There are probably all sorts of stange results possible with
+combinations of the hide options ...
+
+
+Any comments, bug reports/fixes about the HFS parts of genisoimage to the
+address below.
+
+Please state the version, platform and command line used when submitting
+a bug report - the output from "-log-file -v" would help.
+
+Original author: James Pearson (j.pearson@ge.ucl.ac.uk)
+
+This describes the program as shipped with cdrkit, a spinoff from the
+cdrtools project. However, the cdrtools developers are no longer
+involved in the development of this spinoff and therefore shall not
+be made responsible for any problem caused by it. Do not try to get
+support for this program by contacting the original authors.
+
+If you have support questions, send them to
+
+debburn-devel@lists.alioth.debian.org
+
+If you have definitely found a bug, send a mail to this list or to
+
+submit@bugs.debian.org
+
+writing at least a short description into the Subject and "Package: cdrkit"
+
+Source: README.mkhybrid from cdrtools package
+Edited for cdrkit by Christian Fromme <kaner@strace.org> and Eduard Bloch
+
diff --git a/doc/genisoimage/README.prep_boot b/doc/genisoimage/README.prep_boot
new file mode 100644
index 0000000..f406735
--- /dev/null
+++ b/doc/genisoimage/README.prep_boot
@@ -0,0 +1,45 @@
+I have extended mkhybrid to create a CD that is bootable via PPCbug
+on a PowerPC Reference Platform compliant machine (referred to as
+PReP).
+
+This includes a number of IBM RS-6000 clones, along with most of
+Motorola's embedded PowerPC boards, such as the MTX and MVME
+boards. (The motorola boards are sometimes referred to as PowerPlus)
+
+To build a bootable CD, you will first need a kernel image for your
+machine. Put the image somewhere in the filesystem you want
+to generate and ISO9660 image from.
+
+The '-B' or '-prep-boot' flags are used to specify the image file
+to use. The path must be relative to the root of the CD filesytem,
+NOT from the current directory.
+
+For example: to make an image of /tmp/cd and use the image file
+/tmp/cd/zImage, (with rock ridge extensions) use:
+
+mkhybrid -r -B zImage /tmp/cd -o cd.img
+
+Since there are four entries for bootable 'partitions', I have
+allowed up to 4 different images to be used. This might be 
+usefull if one has need of different kernel images for different
+machines on the same CD.
+
+The first image will be in the first partition entry, so if one
+uses:
+
+mkhybrid -r -B zImage1 -B zImage2 -B zImage3 -B zImage4 /tmp/cd
+
+This will result in 4 bootable images. To boot off the first image
+from PPCbug, use 'pboot 0 41' from the ppcbug> prompt.
+(assuming the CDROM is at SCSI ID 4.. replace the 4 with the SCSI
+ID of the CDROM if not.) The second image is at 'pboot 0 42', etc.
+
+There should not be any conflicts with any of the HFS or hybrid
+functions, since the space used by the PReP partition maps is
+unused by anything else. If fact, the goal is to make a CD
+bootable on both Mac's and PReP machines ;)
+
+For any questions contact me at one of the following addresses:
+troy@microux.com
+troy@blacklablinux.com
+hozer@drgw.net
diff --git a/doc/genisoimage/README.releasenotes b/doc/genisoimage/README.releasenotes
new file mode 100644
index 0000000..d4f3898
--- /dev/null
+++ b/doc/genisoimage/README.releasenotes
@@ -0,0 +1,154 @@
+# @(#)README	1.7 99/11/23 joerg
+#                   06/09/11 christian
+
+This describes the program as shipped with cdrkit, a spinoff from the
+cdrtools project. However, the cdrtools developers are no longer 
+involved in the development of this spinoff and therefore shall not
+be made responsible for any problem caused by it. Do not try to get 
+support for this program by contacting the original authors.
+
+Note:
+
+	This program requires a lot of virtual memory to run since it
+builds all of the directories in memory.  The exact requirements
+depend upon a lot of things, but for Rock Ridge discs 12Mb would not
+be unreasonable.  Without RockRidge and without the translation
+tables, the requirements would be considerably less.
+
+
+*****************************
+Notes for version 1.12
+
+	Joliet support is now complete.  See the -J option.
+
+	The file scanning code is much improved - mkisofs can use multiple
+	sources of input files and merge them together to form the output
+	image.  In addition, each source can be grafted at any point in the
+	iso9660 image.
+
+	The image writing code has been cleaned up to make it much easier
+	to add custom extensions.
+
+	The ADD_FILES feature has been removed as it didn't work well,
+and it was hard to figure out.  The recent rearrangements in the
+file scanning code would tend to solve these issues.
+
+*****************************
+Notes for version 1.11
+
+	There is a feature which can be optionally compiled into
+mkisofs that allows you to merge arbitrary directory trees into the
+image you are creating.  You need to compile with -DADD_FILES for my
+changes to take effect.   Thanks to Ross Biro biro@yggdrasil.com.
+
+*****************************
+Notes for version 1.10b1
+
+	Big news is that multi-session capability is very close to being
+	done.  There is still a missing interface to cdwrite that is
+	used to determine the next writable address and the sector number
+	of the last existing session.  Until we get the interface to cdwrite
+	done, this is a beta version.
+
+	Bug involving DST fixed (dates are always calculated, since some
+	files may be DST and other ones would not be).
+
+	Unfortunately the notes on some of the small patches got lost.
+
+*****************************
+Notes for version 1.06
+
+	Jan-Piet Mens <jpm@mens.de> added support for the '-m' switch. This
+	allows exclusion of shell-style globs from the CDROM.
+	See manual mkisofs.8 for more information.
+
+*****************************
+Notes for version 1.05
+
+	Added support for '-r' switch.  This is very similar to -R for
+Rock Ridge, but echos of the development environment are removed
+(i.e. uid/gid set to 0, and permissions of the files are canonicalized).
+Useful in applications where a distribution medium is being produced.
+
+*****************************
+Notes for version 1.04
+
+	No notes for 1.04.
+
+*****************************
+Notes for version 1.03
+
+	No notes for 1.03.
+
+*****************************
+Notes for version 1.02.
+
+	Minor bugfixes here and there.  Support for compiled in
+defaults for many of the text fields in the volume header are now
+present, and there is also support for a file ".mkisofsrc" that can
+also read settings for these parameters.
+
+	A short script "Configure" was added to allow us to set up special
+compile options that depend upon the system that we are running on.
+This should help stamp out the sphaghetti-isms that were starting to grow
+up in various places in the code.
+
+	You should get more meaningful error messages if you run out of
+memory.
+
+*****************************
+Notes for version 1.1.
+
+	The big news is that SUSP CE entries are now generated for
+extremely long filenames and symlink names.  This virtually guarantees
+that there is no limit (OK, well, about 600Mb) for file name lengths.
+I have tested this as well as I can, and it seems to work with linux.
+This would only be used very rarely I suspect.
+
+	Also, I believe that support for VMS is done.  You must be
+careful, because only Stream-LF and FIxed length record files can be
+recorded.  The rest are rejected with error messages.  Perhaps I am
+being too severe here.
+
+	There is a bugfix in the sorting of entries on the disc - we
+need to stop comparing once we reach the ';' character.
+
+	There are four new options -z -d -D -l -V.  Some of these tell
+mkisofs to relax some of the iso9660 restrictions, and many systems
+apparently do not really seem to mind.  Use these with caution.
+
+	Some diagnostic programs to scan disc images are in the diag
+directory.  These are not as portable as mkisofs, and may have some
+bugs.  Still they are useful because they can check for bugs that I might
+have introduced as I add new features.
+
+*****************************
+Notes for version 1.0.
+
+	In version 1.0, the date fields in the TF fields were fixed -
+previously I was storing st_ctime as the file creation time instead of
+the file attribute change time.  Thanks to Peter van der Veen for
+pointing this out.  I have one slight concern with this change,
+however.  The Young Minds software is definitely supplying 3 dates
+(creation, modification and access), and I would strongly suspect that
+they are incorrectly putting the file attribute change time in the
+file creation slot.  I would be curious to see how the different RRIP
+filesystems treat this.  Anyway, this is something to keep in the back
+of your mind.
+
+	The symlink handling was not quite correct in 0.99 - this is
+now fixed.  Only some systems seemed to have been affected by this bug.
+
+	A command line option is now present to allow you to
+specifically exclude certain files from the distribution.
+
+	The case where you do not have permissions to read a directory
+is now handled better by mkisofs.  The directory that cannot be opened
+is converted into a zero-length file, and processing continues normally.
+
+	A few portability things have been fixed (hopefully).
+
+
+Source: README from cdrtools package
+Edited for cdrkit by Christian Fromme <kaner@strace.org>
+
diff --git a/doc/genisoimage/README.rootinfo b/doc/genisoimage/README.rootinfo
new file mode 100644
index 0000000..b3bc447
--- /dev/null
+++ b/doc/genisoimage/README.rootinfo
@@ -0,0 +1,90 @@
+The -icon-position option will attempt to preserve folder window positions,
+scroll bars, views etc. for Apple/Unix file formats that support this
+information (see below for which Apple/Unix encoding are supported).
+
+This information is stored in the 'FinderInfo' part of a Apple/Unix directory.
+For example, in a CAP directory structure a directory called 'dirA' will
+have the necessary FinderInfo stored in file '.finderinfo/dirA'. This file
+stores information including, the folder's location and size on screen,
+its scroll positions, folder View (view as Icons, Small Icons, etc.).
+
+However, the similar FinderInfo data for the 'root' folder is a special case.
+For example, if a directory called '/some/dir/macfiles' is a CAP volume that
+is mounted on a Mac as 'macfiles', then the FinderInfo for this directory
+is stored in the file '/some/dir/.finderinfo/macfiles' - which is outside
+the CAP directory structure.
+
+To get round this, an extra option, '-root-info' is used that takes as its
+argument the name of the file that stores the root folder's FinderInfo.
+
+Using the above example, the command file options will be something like:
+
+% mkhybrid --cap -root-info /some/dir/.finderinfo/macfiles /some/dir/macfiles
+
+The format of the root FinderInfo file must be the same as the 'double-dash'
+option(s) given on the command line.
+
+The Apple/Unix encodings that mkhybrid can decode the root FinderInfo are:
+
+CAP:
+	CAP directory:		/some/dir/macfiles
+	Root FinderInfo file:	/some/dir/.finderinfo/macfiles
+
+Netatalk:
+	Netatalk directory:	/some/dir/macfiles
+	Root FinderInfo file:	/some/dir/.AppleDouble/RootInfo
+
+EtherShare:
+	EtherShare directory:	/some/dir/macfiles
+	Root FinderInfo file:	/some/dir/.rsrc/macfiles
+
+If an HFS disk is mounted on a Linux platform, then the root FinderInfo
+files are:
+
+Option 'fork=cap':
+	Root FinderInfo file:	/mountpoint/.rootinfo
+
+Option 'fork=double':
+	Root FinderInfo file:	/mountpoint/%RootInfo
+
+Option 'fork=netatalk':
+	Root FinderInfo file:	/mountpoint/.AppleDouble/RootInfo
+
+
+The '-root-info' option implies the '-icon-position' option. Future releases
+of mkhybrid may automatically find the root FinderInfo file.
+
+The volume name is not set from the root FinderInfo file. Use the -V or
+-hfs-volid options to set the volume name.
+
+Currently UShare, SGI/XINET, PC Exchange and SFM Apple/Unix root FinderInfo
+files are not supported by mkhybrid - more information about these formats
+is required in order to supoort them.
+
+AppleSingle and MacBinary are file only formats - they don't support folders
+or volumes.
+
+Using this option, it is now possible to make a nearly true representation
+of a Mac folder layout on a Unix/Linux platform.
+
+Original author: James Pearson 26-Apr-2000
+
+This describes the program as shipped with cdrkit, a spinoff from the
+cdrtools project. However, the cdrtools developers are no longer
+involved in the development of this spinoff and therefore shall not
+be made responsible for any problem caused by it. Do not try to get
+support for this program by contacting the original authors.
+
+If you have support questions, send them to
+
+debburn-devel@lists.alioth.debian.org
+
+If you have definitely found a bug, send a mail to this list or to
+
+submit@bugs.debian.org
+
+writing at least a short description into the Subject and "Package: cdrkit"
+
+Source: README.rootinfo from cdrtools package
+Edited for cdrkit by Christian Fromme <kaner@strace.org>
+
diff --git a/doc/genisoimage/README.session b/doc/genisoimage/README.session
new file mode 100644
index 0000000..a4126fb
--- /dev/null
+++ b/doc/genisoimage/README.session
@@ -0,0 +1,53 @@
+/* @(#)README.session	1.3 99/03/02 eric */
+
+	This release of genisoimage has basic support completed for
+multiple sessions.  However, we still need some interaction 
+between wodim and genisoimage for this to work correctly. This is needed as
+only wodim knows the different ways to gather these numbers for all 
+different drives. It may be that future versions of genisoimage will include 
+the needed support for MMC compliant drives.
+
+	There are a few new options to genisoimage to allow for this.
+The first one is "-M /dev/scd0", and is used so that genisoimage can examine
+the entirety of the previous image so that it can figure out what additional
+files need to be written in the new session. Note that there are operating
+systems that don't allow to read from CD drives with a sector size
+of 2048 bytes per sector. To use genisoimage on such an operating system, you
+will need a version of genisoimage that includes the SCSI transport library 
+from wodim. Simply use the dev= syntax from wodim with -M in
+such a case. It will tell genisoimage to use the SCSI transport library to 
+read from the CD instead of using the standard read() OS interface.
+
+	There is also a temporary hack in genisoimage in the form of a '-C' option.
+The -C option takes two numbers as input, which are delimited by commas.
+For example, you could specify "-C 1000,1020", but you should never just
+make up numbers to use here.  These numbers are determined from wodim.
+
+	Note that if you use -C and omit -M, it effectively means that
+you are writing a new session, starting at a non-zero block number,
+and you are effectively ignoring all of the previous session contents.
+When this session is sent to the writer, the new session effectively
+"erases" the previous session.
+
+	In practice you should be able to do something like:
+
+genisoimage [other options] -C `wodim dev=b,t,l -msinfo` \
+		-M /dev/cdblkdev
+
+Replace 'b,t,l' by the aproriate numbers for SCSIbus, target and lun
+of your drive.
+
+Note: As of the 1.12b5 release, the multi-session technology has
+matured quite significantly.  It is entirely possible that bugs
+exists, or that further tweaks will be required somewhere along the
+way to get things working correctly.  The data gathering mode of
+wodim has been tested, and I believe it works correctly.  Caveat
+Emptor.
+
+[Mar 1, 1999].
+
+
+Source: README.session from cdrtools package
+Edited for cdrkit by Christian Fromme <kaner@strace.org> and 
+Eduard Bloch <blade@debian.org>
+
diff --git a/doc/genisoimage/README.sort b/doc/genisoimage/README.sort
new file mode 100644
index 0000000..1e377bc
--- /dev/null
+++ b/doc/genisoimage/README.sort
@@ -0,0 +1,102 @@
+Sort the order of file data on the CD
+=====================================
+
+Note: this option does not sort the order of the file names that appear
+in the ISO9660 directory. It sorts the order in which the file data is
+written to the CD image.
+
+This option is useful in order to optimize the data layout on a CD.
+
+To use, type something like:
+
+genisoimage -o cdimage.iso -sort sort_file [other_options] cd_dir
+
+The file 'sort_file' contains two columns of:
+
+filename	weight
+
+where filename is the whole name of a file/directory as genisoimage will see it
+and weight is a whole number between +/- 2147483647
+
+The files will be sorted with the highest weights first and lowest last.
+The default weight is zero.
+
+If the filename is a directory name, then all the files in that directory (and
+sub-directories) will use its weight as their default weight.
+
+e.g.
+
+If the directory 'cd_dir' contains two directories called 'dir1' and 'dir2'
+with files 'A', 'B' and 'C' in dir1 and 'X', 'Y' and 'Z', the the file
+'sort_file' could look something like:
+
+cd_dir/dir2	1000
+cd_dir/dir2/Y	2000
+cd_dir/dir1/B	-2000
+cd_dir/dir1/A	-8000
+
+Note: There must be only one space or tab character between the filename and
+the weight and the weight must be the last characters on a line. The filename
+is taken to include all the characters from the first in a line, up to, but
+not including the last space or tab character on a line. This is to allow
+for space characters to be in, or at the end of a filename.
+
+
+The command:
+
+genisoimage -o cdimage.iso -sort sort_file cd_dir
+
+will sort the above file data as:
+
+cd_dir/dir2/Y
+cd_dir/dir2/X
+cd_dir/dir2/Z
+cd_dir/dir1/C
+cd_dir/dir1/B
+cd_dir/dir1/A
+
+Note: files 'X' and 'Z' both have the weight 1000 - their sort order will then
+be the normal ISO9660 sort order (i.e. alphabetical in this case).
+
+File C will have the default weight of 0
+
+Warning: the filenames in the sort list MUST match the whole path as seen by
+genisoimage. i.e. in the above case, if the command line was:
+
+genisoimage -o cdimage.iso -sort sort_file ./cd_dir
+
+then the sort_file filename will have to changed as accordingly.
+
+Notes
+=====
+
+CDs are written from the middle outwards. High weighted files will be nearer
+the inside of the CD.
+
+Wildcards in the filename list should work.
+
+If a file appears more than once in the source directory tree, then the file
+is only added once to the CD image - i.e. a hard linked file, or symbolic
+link if using the -f option. The file will be sorted according to the
+highest weighting given to any of the linked files.
+
+Zero length files are not sorted - the 'start extent' *may* appear to be in
+the middle of another file after sorting. This is because zero length files
+are given the start extent after the last file added to the CD at that time.
+This address is not changed by the sorting, so it may appear that the file
+address is in another file - however as they are zero length, this will
+not matter!
+
+Directories are not sorted by this flag - directories HAVE to be in the
+ISO9660 sort order - however, the files the directory entry points to, can be
+anywhere on the CD.
+
+Existing files from any previous sessions will not be sorted - they already
+exist on the CD and can not be moved!
+
+I have no idea if this is really useful ...
+
+
+James Pearson 22-Nov-2001
+
+Any comments/problems to j.pearson@ge.ucl.ac.uk
diff --git a/doc/genisoimage/README.sparcboot b/doc/genisoimage/README.sparcboot
new file mode 100644
index 0000000..b9bcbf2
--- /dev/null
+++ b/doc/genisoimage/README.sparcboot
@@ -0,0 +1,77 @@
+# @(#)README.sparcboot	1.1 99/12/12 joerg
+# Edited for program name change by Eduard Bloch, 2006
+
+The sparc boot feature does allow you to create your own Sun sparc boot disk.
+This will allow you to create modified Solaris install disks or to create
+installation CD's for other OS that run on sparc systems.
+
+A CD that is bootable on a Sun sparc system has a Sun disk label on sector 0
+and some Sun sparc disk partitions behind the ISO-9660 filesystem image.
+
+The layout of a sparc boot CD:
+
+----------------------------------------------------------------------------------------------------
+|Sun disk label| Iso 9660 filesystem |Generic sun4 boot|sun4c boot|sun4m boot|sun4d boot|sun4e boot|
+----------------------------------------------------------------------------------------------------
+
+On older system CD's all boot partition contain a full UFS miniroot filesystem.
+On newer CD's the images on slice 2 and above only contain boot redirects to
+slice 1.
+
+To create a CD that is bootable on Sun sparc systems you need to have the
+boot images for the apropriate sparc architecture.
+
+A boot image file usually is a UFS filesystem image that contains the 
+primary boot image at byte offset 512 ... 8191.
+
+You may get such boot images by extracting partitions 1..5 from a Sun Solaris install CD,
+but any bootable image should work.
+
+Here is an expample how to do this with the Solaris 7 install CD.
+
+dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s1 of=sun4
+dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s2 of=sun4c
+dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s3 of=sun4m
+dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s4 of=sun4d
+dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s5 of=sun4e
+
+
+genisoimage -R -sparc-boot sun4,sun4c,sun4m,sun4d,sun4e -o boot.img /mnt/install
+
+Will create the bootable image in boot.img.
+
+If you like to make the boot images smaller, you may call 'fstyp -v'
+on the images and use the 'size' value to get the needed minimal 
+boot image size in kB.
+
+The result for the S7 boot CD is:
+
+ufs
+magic   11954   format  dynamic time    Wed Oct  7 00:00:30 1998
+sblkno  8       cblkno  12      iblkno  16      dblkno  252
+sbsize  2048    cgsize  2048    cgoffset 20     cgmask  0xfffffff0
+ncg     7       size    25704   blocks  23987
+			^^^^^
+			This is the number of interest.
+bsize   8192    shift   13      mask    0xffffe000
+fsize   2048    shift   11      mask    0xfffff800
+frag    4       shift   2       fsbtodb 2
+minfree 10%     maxbpg  2048    optim   time
+maxcontig 256   rotdelay 0ms    rps     90
+csaddr  252     cssize  2048    shift   9       mask    0xfffffe00
+ntrak   14      nsect   72      spc     1008    ncyl    102
+cpg     16      bpg     1008    fpg     4032    ipg     3776
+nindir  2048    inopb   64      nspf    4
+nbfree  1768    ndir    667     nifree  24329   nffree  9
+cgrotor 2       fmod    0       ronly   0
+
+So you should call:
+
+dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s1 of=sun4 bs=1k count=25704
+
+To modify this filesystem, you can mount it using the fbk driver:
+
+chmod +t ./sun4		# Need to do this to avoid vm cache aliasing problems
+
+mount -F fbk -o rw,type=ufs /dev/fbk0:sun4 /mnt
+
diff --git a/doc/genisoimage/README.sunx86boot b/doc/genisoimage/README.sunx86boot
new file mode 100644
index 0000000..2286a57
--- /dev/null
+++ b/doc/genisoimage/README.sunx86boot
@@ -0,0 +1,77 @@
+# @(#)README.sunx86boot	1.3 05/02/25 Copyright 2003 J. Schilling
+# Edited for program name change by Eduard Bloch, 2006
+
+A Solaris x86 Boot CD looks the like this:
+
+-	A PC type fdisk partition map is in CD sector 0 at offset 0
+	This fdisk partition map contains a single Solaris 0x82 type
+	partition starting at CD sector 0 at offset 512.
+
+-	A SVr4 disk partition label is at CD sector 0 at offset 1024.
+	This equates the usual 512 byte offset to the primary partition
+	used by SVr4.
+
+	This SVr4 partition label defines:
+
+	-	Partition 0 to contain a usually UFS type boot filesystem
+
+	-	Partition 1 to map the ISO-9660 filesystem.
+
+		This seems to be a conceptual bug from Sun, as it is
+		impossible to mount this partition because this partition
+		would point outside the primary fdisk partition type 0x82
+
+	-	Partition 2 maps the whole CD.
+
+
+A boot CD created by Sun contains a master boot record in CD sector 0 offset 0.
+The size if this MBR is 0x1BE (446 decimal) as usual on PCs.
+
+At CD sector 0 offset 512, there is a "primary boot sector". The MBR assumes
+that is always gets loaded together with the ""primary boot sector".
+
+The El-Torito map for this CD defines a "no-emulation" boot sitting at CD sector 0
+and being 4 512 byte sectors in size. This covers the 1024 bytes of above 
+boot code. Note that genisoimage will not put the no-emulation boot at sector 0
+as it keeps the boot inside the area used for other file content data.
+
+At CD sector 1..15, there is a secondary boot code that understands UFS and tries
+to boot from UFS slice 0. If you like to boot from different filesystem types,
+you need to replace this boot code. The real size used by the secondary boot
+is 31 x 512 bytes == 15872 bytes.
+
+To get hold of the three boot files, do the following with e.g. a Solaris 10
+boot CD:
+
+readcd dev=1,0 f=CD.out sectors=0-32
+
+Replace dev=1,0 with the apropriate values for your system (see readcd -scanbus).
+
+sdd if=CD.out bs=446 count=1 of=mboot
+sdd if=CD.out count=1 iseek=512 of=pboot
+sdd if=CD.out count=60 iseek=2048 of=bootblk
+
+To create the needed files for the misofs command line example below, do the
+following:
+
+sdd if=mboot -fill of=eltoritoboot
+cat pboot >> eltoritoboot
+
+sdd -inull bs=2k count=1 of=genboot
+cat bootblk >> genboot
+
+If you like the CD to look more similar to the original Sun CDs, use:
+
+cp eltoritoboot genboot
+sdd -inull bs=1k count=1 >> genboot
+cat bootblk >> genboot
+
+If you like to create a CD similar to the Solaris 10 boot CD, do the following:
+
+mkdir isodir
+star -cPM -C /vol/dev/dsk/c1t1d0/multi_icd_sol_10_x86/s2 . | star -xp -xdot -C isodir
+cp eltoritoboot isodir/.bootimage
+
+genisoimage -G genboot  -no-emul-boot -b .bootimage -c .catalog -R -o bootcd.iso -sunx86-boot /vol/dev/dsk/c1t1d0/multi_icd_sol_10_x86/s0 isodir/
+
+