1Notes on using the --osx-hfs option when running mkisofs on MacOS X
2
3mkisofs does not use any of the MacOS APIs to access files - it uses
4standard (POSIX style) library calls. Under normal circumstances, all
5mkisofs will 'see' is the data fork of files on an HFS (or HFS+) file system.
6
7However, Apple have provided a way for POSIX style applications to
8access the resource fork - using the following syntax:
9
10If a file exists on an HFS volume with the name 'foo', then the resource fork
11can be accessed using the file name 'foo/rsrc' or foo/..namedfork/rsrc'
12(the data fork can also be accessed using 'foo/..namedfork/data').
13
14These 'pseudo' file names are not normally visible in a directory - unless
15you access them directly (e.g. 'ls -l */rsrc etc).
16
17To access the finder information, Apple have provided an undocumented library
18function called getattrlist(). Fortunately there are example of its usage
19in the Darwin (MacOS kernel) source code.
20
21
22Although MacOS X can use HFS(+) as its file system, Apple have decided to
23move away from using HFS to store finder info and resource data - for
24example, the TYPE of a file may be based on its file name extension and the
25TYPE field in the finder info empty.
26
27mkisofs knows nothing about these file name extension mappings, so if the
28--osx-hfs option is used and the source files are on MacOS X HFS(+) volumes,
29by the fact that they are HFS files, they will get identified as 'MacOS X HFS'
30and the resulting file on the output CD image will have empty TYPE and CREATOR
31fields.
32
33Therefore, if the input finderinfo is blank and the the resource fork is
34empty, mkisofs will assume the input file is not a 'real' HFS file - which
35means the TYPE and CREATOR may then be set using the file's magic number or
36mkisofs' file name extension mapping.
37
38The only real benefit of using the --osx-hfs option is when the source files
39are on an OS9 or earlier HFS or HFS+ volume e.g. an existing HFS CD.
40
41James Pearson 3-Jul-2002
42