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