Brett Lymn writes:
> According to Peter Galbavy:
>> There is two parts to this. One if the software to create ISO9660 format
>> file systems, which can then be put onto anything. I tried this with a
>> floppy and SunOS mounted it fine as an hsfs filesystem.
> 
> Careful with this!  The HSFS != ISO9660, at least in SunOS implementations.

Your first mistake is assuming the brain-damaged SunOS HSFS driver is any
sort of a canonical reference point.  It's probably the least-capable HSFS
driver I've seen out there.  (Then there's the fact that the CD-ROM driver
can't see more than one slice on a CD-ROM; at least Solbourne got that right.)

> For the most part an ISO9660 CD will work when
> mounted as HSFS but there are some file types that are quietly ignored

They aren't "quietly ignored"; as you noted later, you'll get an error
message to the effect of "hsfs: filetype (0x%x) not supported" on the console.

> by Sun's code - the upshot being that you will not find some files
> that should be there.  I had a user here at work that got hold of some
> of the NASA Voyager CD's which we mounted on our Sun server - he could
> see a lot of the images but there were some files that just did not
> show up, which worried me until I found out about the unknown file
> types (actually, I think the Sun does whine to the console about
> unknown file type 0xYY, but I am not sure about that now)

If you look at the SunOS <hsfs/hsfs_spec.h>, you'll find

/* mask bits for HDE_FLAGS */
#define HDE_EXISTENCE           0x01    /* zero if file exists */
#define HDE_DIRECTORY           0x02    /* zero if file is not a directory */
#define HDE_ASSOCIATED          0x04    /* zero if file is not Associated */
#define HDE_RECORD              0x08    /* zero if no record attributes */
#define HDE_PROTECTION          0x10    /* zero if no protection attributes */
#define HDE_UNUSED_FLAGS        0x60
#define HDE_LAST_EXTENT         0x80    /* zero if last extent in file */
#define HDE_PROHIBITED  (HDE_DIRECTORY | HDE_ASSOCIATED | HDE_RECORD | \
                                HDE_LAST_EXTENT | HDE_UNUSED_FLAGS)

In particular, the ones you run across on SunOS are the HDE_ASSOCIATED and
HDE_RECORD types.  The HDE_RECORD types are commonly found on NASA CD-ROMs,
because a lot of those CD-ROMs germinate from images that are created on
VAX/VMS (or VAX/OpenVMS or Alpha/OpenVMS) systems that *do* support these
"record" attributes in their High Sierra/Rock Ridge implementations.  You
will commonly find HDE_ASSOCIATED file types on ISO9660 CD-ROMs created for
the Macintosh market, as "associated" attributes essentially allow one to
have two filenames that are exactly the same in the same directory, which
I believe is how data and resource forks are handled for Mac CD-ROMs.  (I
have seen a Mac ISO9660 CD-ROM that was filled with GIF images, and every
single file had the HDE_ASSOCIATED attribute with 2 files for each image.)

Even present-day Solaris can't handle these "Record" attribute files.  We
have to put

* Next entries are to enable reading PDS CD-ROMs with "Record" entries
set hsfs:ide_prohibited = 0xe6
set hsfs:hde_prohibited = 0xe6

into /etc/system ...

In a vain attempt to keep this remotely NetBSD related, it would be
Really kUUl if our driver supported these file types.  It might even get us
some "ins" at NASA sites that are sick of kludging around the SunOS
inability to read NASA CD-ROMs  :-)

(A cursory glance at cd9660_lookup.c and cd9660_vnops.c seems to indicate
 that the ASSOCIATED types are supported, at least ... bravo)

	- Greg