Hi,

> > 2) What _is_ the wrong way to burn a CD on NetBSD? The right way?
> 
> Wrong: linkcount of 2 when the directory is not empty.
> Right: 2 possibilities:
>          1. the correct linkcount, which is not supported AFAIK by
>             ISO 9660.
>          2. linkcount 1

Well, let's try (again?) to set things straight:

ISO 9660 in itself doesn't know anything about linkcounts.

However, it does allow for various extensions which may be used to record
additional information for any directory entry.

Our implementation of the cd9660 filesystem supports bare bones 9660 CDs
as well as various extensions.  One of the extensions supported, the
Rock Ridge extension, does support (among other things) the recording
of linkcounts for every directory entry.

Now the "find" utility:  It has an optimization (IIRC inherited from the
fts library function) that avoids "stat(2)"-ing the files in a directory
if it determines that there "cannot" be subdirectories in that particular
directory by the fact that the linkcount of the parent directory is 2.

Since determining the number of subdirectories of some directory isn't
easy (you'd have to read all of the directory, analyze its entries and
count the number of directories in there), our cd9660 filesystem, when
accessing a bare bones ISO 9660 CD, fakes by returning a linkcount of
just 1 for directories (as for other files, too).  Any number other
than 2 would do here (for the purpose of getting find to actually
check each directory entry for the possibility of being a subdirectory).

Now if you record Rock Ridge extended directory entries on the CD,
our cd9660 filesystem relies on the data actually recorded on the disk.
Among others, it returns the linkcount that is recorded within these
extensions.

Now if you record a directory entry with a linkcount of 2 in its
Rock Ridge extension despite the fact that this directory does have
subdirectories, you loose.

Hope this explains things a bit.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     Wolfgang Solfrank, TooLs GmbH 	+49-228-985800