[Libcdio-help] suggestions for API changes

[R. Bernstein]

Geoffrey Brown writes:
 > 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)

I can't get to this URL (The message is: Sorry, we couldn't find the
requested document), but I suppose this isn't essential.

 > 
 > 
 > 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.

I'm not sure where you mean here. Do you mean the enum called "type" in
the iso9660_stat_s structure which currently has 1 for file, and 2 for
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

I am amenable to changing the API if you want to suggest something and
it looks reasonable. 

 > 
 > 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 don't see that setting the blocksize requires exposing
_iso9660_s. Couldn't a routine which just sets the size work as well?

At any rate, by all means the source code is there so please test
changing it. There are regression tests so if you run those and none
of those break, you are probably okay. Or we have to add more tests
which is also okay.

 > 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
 >