Notes on using the --osx-hfs option when running mkisofs on MacOS X

mkisofs does not use any of the MacOS APIs to access files - it uses
standard (POSIX style) library calls. Under normal circumstances, all
mkisofs 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.

mkisofs 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, mkisofs 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
mkisofs' 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