[Libcdio-help] suggestions for API changes

[Geoffrey Brown]

As part of a research project to make thousands of CDROMs published by
the federal government available
on line, we've beaten on libiso9660 pretty hard and have a few
suggestions for API deficiencies that could
be addressed  (http://www.cs.indiana.edu/svp)


1)   Approximately 450 CDROMs we've looked at have APPLE file systems
consisting of separate
      data and resource files with identical names.  The only way to
distinguish these are the file_flags
      in the raw directory.     A modest change to enable accessing
such low-level information would be
      a variant of readdir that returns a list of "raw" directories.
Coupled with exposing the dir to stat function
      this could be quite useful

2)  Out of approximately 4500 CDROMs we found one with a 512 byte
sector size.   libiso9660 is largely
     hardwired for 2048 byte sectors, though it is possible to set the
sector size by exposing the _iso9660_s
     structure in the pointer returned from iso9660_open to set the
appropriate field.   I haven't tested this
     enough to know whether this might expose bugs.  I quick scan of
the source code suggest that
     sector sizes larger than 2048 could be a problem

3) Problems with name lookup -- we've found that the name returned by
iso9660_name_translate_ext cannot
    be reliably used to find a file.  Thus, in our website, we use the
statbuf->filename for lookups and the translated
    name for the user visible string

In the process of building this archive we learned many ugly truths
about CDROMs.   One that may surprise
people is that often the volume size in the volume header is wrong --
both too great and too small.   When copying
images in windows,  this can lead to truncated files (if the
advertised size is smaller than the actual image).   Many
sites recommend using the volume size with dd to rip the correct
amount of data.  This is bound to fail frequently.
The only way to be sure that you've copied everything is to "walk" the
file system with something like libiso9660
to ensure that all files (including directories) fall within the image
you've created.

We've also used automounting on linux to access collections of images.
 This approach works, but doesn't scale
well and is also limited to images on local disks (OS X doesn't have
this limitation).   automounting images fails
silently if all the available loopback devices are in use, so it's
pretty bad if you want to use something like
find on a collection of images.

Geoffrey Brown