*******************************************************************************


Bug SSDhp04723                     online_UDF               Submitted 960408
  ASSIGNED defect report      ArchiveObject, version udf_bet Assigned 960503
                                 1 enclosure
 
LogicalVolumeInfo structures are unused
 
No use is made of the three UDF-defined fields in the OSTAVolumeDescriptor.
These fields are supposed to hold OwnerName, OrganizationName, and
ContactInformation, but since it is not mandatory, we are not supplying them.

To change this, we will need to supply extra methods to get this information
into the Archive object -- perhaps a new structure holding multiple strings --
and then alter the nsrExport to call the methods.

No change is recommended at this time.

-DVM 4/8/96


*******************************************************************************


Bug SSDhp04948                     online_UDF               Submitted 960408
  ASSIGNED defect report      Descriptors, version udf_beta  Assigned 960409
                                 1 enclosure
 
Remove implementationID from FIDs
 
Performance improvement available for reading and writing
directories. We can now remove the ImplementationID from FID.

NOTE that this is also a capacity improvement.

UDF does NOT require this.


*******************************************************************************


Bug SSDhp04956                     online_UDF               Submitted 960503
  ASSIGNED defect report      OnlineObjects, version 3/15    Assigned 960503
                                 1 enclosure
 
PhysExtents MUST be limited to 30bit lengths
 
The standard says (in some small corner) that ExtentDescriptors
('extent_ad's) must be limited to 30-bit lengths, even thought they do
not have their extent type encoded into their most significant two
bits, as do the short_ad, long_ad, and extended_ad types.

The PhysExtent class should somehow prevent this --- Perhaps support
an error() method which checks for this. Or, it could go in the
toISO() places --- probably not the latter.


*******************************************************************************


Bug SSDhp04953                     online_UDF               Submitted 960503
  ASSIGNED defect report      AuxilliaryObjects, version 3/1 Assigned 960503
                                 1 enclosure
 
ByteArrayRef needs better support for ByteArray reallocations
 
We changed the ByteArrayRef class to support a char * constructor, and
then reworked it to NOT depend upon a ByteArray. However, those who
construct it from a ByteArray would LIKE to be able to perform all the
normal operations on their ByteArray without making the reference not
work, and this now happens. For example, the insert() method causes a
reallocation, which renders the BARef invalid.

The fix is to make an abstract base class and derive both a BA-based
and a char *-based version from it.

We've already talked about the vulnerability of the new
ByteArrayReference to changes in length of it's ByteArray, and how this is
exacerbated by my insertBytes and removeBytes methods, which both change the
length of the ByteArray.  Since we were the ones that pushed for this new
ByteArrayReference constructor, it just goes to show: you should be careful
what you ask for--you might get it.



*******************************************************************************


Bug SSDhp04957                     online_UDF               Submitted 960503
  ASSIGNED defect report      Descriptors, version 3/15      Assigned 960503
                                 1 enclosure
 
Volume Initialization MUST support some sort of TagSerialNo incrementing
 
UDF requires that whenever the volume label stuff is laid down, the
TagSerialNumber must be different, recommending that it be incremented
from what it finds on the current PVD (I think).

We need to help users do this, although we can never enforce it. If
not helping them, we at least need to document it.


*******************************************************************************


Bug SSDhp04749                     online_UDF               Submitted 960408
  ASSIGNED defect report      ArchiveObject, version udf_bet Assigned 960503
                                 1 enclosure
 
PVD::InterchangeLevel not at 2

Interchange Level must be set to 2 for ALL single-surface volumes, whether
written by the Archive Object or the SSLIB. Therefore, WHEN the
SSVolume::toISO() method is written, it should take this into account.


*******************************************************************************


Bug SSDhp04954                     online_UDF               Submitted 960503
  ASSIGNED defect report      Descriptors, version 3/15      Assigned 960503
                                 1 enclosure
 
EAInspector needs to support fromISO() on limited amount of memory
 
Cary Boyd of SAI NEEDS the EAInspector to handle fromISO() properly
from a limited area of memory -- only try to translate up until the
limit of the buffer.

He has implemented this inside of his ss/nsrEAttr code, and it should
be moved into the descr/nsrEA.XX.

It is called SAIEAInspector.


*******************************************************************************


Bug SSDhp04955                     online_UDF               Submitted 960503
  ASSIGNED defect report      Descriptors, version 3/15      Assigned 960503
                                 1 enclosure
 
Support Borland's 16-bit enum limitation
 
>16 bit enums are still not supported on Borland, so need some
ifdef support for that. They have hard-coded a value, rather than
using the enum. This shows up in descr/nsrEA.h, where ApplUseEAs is an
enum with a value greater than 64K (thankyou, ISO).

We should do some sort of ifdef stuff around it, with it documented
with an appropriate define, and placed inside of config/nsrCfg.h, like
all the OS/2 limitations.


*******************************************************************************


Bug SSDhp04958                     online_UDF               Submitted 960503
  ASSIGNED defect report      Descriptors, version 3/15      Assigned 960503
                                 1 enclosure
 
Various descrTst problems from Mountain Optech
 
UPDATE.............UDF / Ron Stawicki/Update for DESCRTST
>
>Dave,
>
>We've followed your initial recommendations regarding DESCRTST, which we've
compiled, linked, and executed as a WIN32 flat model console app. We've run
into a series of emitted errors and a throw exception towards the end of the
test. We've discovered so far the following issues:
>
>        1) DESCRTST #491 - it appears that the "rid" string member is hard
coded to a length of 23, and "ws" is actually 21; therefore, the lengths do
not compare and that component fails, therefore emitting the error message.
>
>        2) DESCRTST #791 - in converting back to a time_t long for
"modificationTime", there's a TZ adjustment which changes the time
(-60*....) and hence causes a miscompare error message to be emitted
(NSR_VERIFY is defined).
>
>I'm investigating the remainder of the issues with this test, and should be
able to share the rest of these early next week. 
>

Dave, I've completed issues with DESCRTST, with items reported as follows;
in some cases, I've assumed that code sections were "isolated", so to
continue on, I set up a #ifdef in that section and recompiled to go on to
the next issue; therefore, some of the line numbers might be off by a few lines:

        3) DESCRTST #818 - same modification time error
        4) DESCRTST #868 - "   "
        5) DESCRTST #905 - empty "ffid" - null string throws exception in
NSRTPES.CPP         #409    
        6) DESCRTST #1151 - rovd.clear() /nsrVol #98 bodyClear()/nsrVol
#1198 logicalVolumeId.clear throws exception
        7) DESCRST #1209 - same as item 6
        8) ~DESCRTST #1568 - emitted error message "FreeEASpace.attrID=null"
                & macVolumeInfoEA.attrID()==null
        9) ~DESCRTST #1653 enitted MacDirFinderInfoEA.attrID() = null
        10) ~DESCRTST #1764 - (same as item 9)
        11) ~DESCRTST#1886 - emitted MacUniqueIDTableEA.attrID()=null
        12) ~DESCRTST#2004 - emitted MacResiurceForkEA.fixedLen() = null
        13) DESCRTST #2057/nsrEA.cpp #2675 - "SupportedEAType eat =
eatype()".......throws exception



*******************************************************************************


Bug SSDhp04676                     online_UDF               Submitted 951204
  OPEN defect report          SSLIB, version udf_beta
                                 1 enclosure
 
Assist unique 16 characters at front of Vsname
 
Unique String at front of VolumeSetIdentifiers is not enforced or helped.
- Document UDF Requirement, and corresponding responsibility of app writer.
- Document error if try to break it.
- Provide helper class to generate string?
  - takes in a desired name, and tacks on a unique handle to its beginning.
- Enforce it only on addUnlabeledVolume(), and still read ones with
  any name. This is absolutely consistent with UDF, since we cannot
  guarantee that absolute uniqueness will always occur.
  PLUS, we need to read Maestro volume sets...


*******************************************************************************


Bug SSDhp04676                     online_UDF               Submitted 951204
  OPEN defect report          SSVolume, version udf_beta
                                 1 enclosure
 
OSTA padding in external EA space
 
I've uncovered cases of padding in the external EA space where the OSTA
spec gets a little fuzzy.  Consider this example:
      various ISO and/or Implentation Use EAs
      .
      .
      .
      long Implentation Use EA (multiple of block size)
      short Application Use EA (100 bytes)
      [Free Space EA needed here for padding] <---
      long Application Use EA (multiple of block size)
As the spec stands today, it doesn't specify that short application use EAs
must come before long ones.  So these application use EAs could be placed
with any longs first, then any shorts, and be fully compliant.

I believe we discussed that for consistency, the spec should be changed to
specify that application use EAs follow the same rule as implementation use
EAs: that shorts must be placed before longs. If this change is made to the
spec, then we would need a new type of EA--an Application Use Free Space EA.
The spec could be easily modified by changing section 3.3.4.5.1 to change
"This extended attribute shall be stored as an Implementation Use Extended
Attribute whose Implementation Identifier..." to "This extended attribute
shall be stored as either an Implementation Use Extended Attribute, or an
Application Use Extended Attribute, whose Implementation Identifier...".

My implementation of the extended attributes does always place short
Application Use EAs before long ones.  It tries to do all padding by
extending the attribute length of individual attributes, but there are cases
where this isn't possible.  In those cases it currently inserts an
Implementation Use Free Space EA; this is a clear violation of the OSTA spec.

What do you think about this?


*******************************************************************************


Bug SSDhp04676                     online_UDF               Submitted 951204
  OPEN defect report          SSVolume, version udf_beta
                                 1 enclosure
 
LogExtent leak/duplication Hazard

In the definition of LogExtents, we went to GREAT LENGTHS to ensure
that space would not be easy to lose, or end up with duplicate
references, etc. The principal approach was to DISALLOW the
construction of LogExtents out of an address, etc. RATHER, they are to
ONLY come from SpaceResources or from the ADs on the disk.

Unfortunately, the whole notion of allowing the chopping up and
reassembling of LogExtentLists, as well as simply the assignment
operator, introduce occasions to have multiple references and lost
references to the disk space. SAI has done the most programming with
the LogExtentLists (specifically, Cary Boyd has), and he would like
something more robust.

It appears that using the lisp-like approach to chopping lists up
(with non-destructive operations occurring) basically implies that we
probably need some sort of garbage-collection. Here, we specifically
need garbage collection or consistency insurance for the disk space,
rather than for memory.

Without any help in this arena, we will (doubtless) have disk space
leaks, etc.

It seems to me that we have several alternatives:

1. We could leave it "as-is".
2. We could implement some sort of disk space "purify"-like
   instrumentation, which could help developers to somehow ensure that
   they do not have leaks, etc. The overhead of this would, like
   Purify, only be incurred when a compile option were set, or
   something like that. Thus, during normal operation, this would not
   be executing.
3. We could implement a sort of behind-the-scenes consistency
   ENFORCER, which would throw exceptions if rules were ever
   violated. The rules could be...
   - Only one AD in an FE may refer to any space on the disk.
   - Multiple ICBAddress fields may point to the same disk space.
   - No space in the FST/FSB, etc. may be referenced by an entry in an
     FE.
   To enforce this, some sort of reference count could be implemented,
   etc.
4. We could implement some sort of AUTOMATIC freeing of unused
   space. Perhaps this would involve each LogExtent having a
   relationship with the SpaceResource, such that it could either go
   onto the disk as an AD or would necessarily go into the
   SpaceResource.

My current thoughts on this are that the abstractions are at a lower
level than what would be required to make fancy stuff work. The
abstractions defined are simply bundled-together references to disk
space. If we were to try to make them less hazardous to use, we would
most likely have to look at the problem with the LogExtentLists at the
absolute center, where NO operator=() would be supported, as well as
no non-destructive chopping up methods (such as head() or
tail()). Extents would no longer be simply variables to hold
information about disk space, but would rather be objects holding data
as well, and supporting persistence. So, they would be like persistent
data buffers. The address of them would be a KEY to get the one in
which a user is interested. The question would (of course) arise as to
how OODB models protect against such hazards themselves. Do such
objects NEVER get destroyed? -- Or do they, upon deconstruction,
either write themselves out (if modified), or simply pass into the
ether? 

Perhaps the RW Tools.h++ V7 notions of persistence could lend a hand
understanding the potential here.

Here are the thoughts from Cary Boyd of SAI:
 
 This isn't a specific problem or error, but just a chance for me to
 whine a little.  I know its pretty late in the game to be making
 fundamental changes, but here are some thoughts I have.
 
 The EA implementation has really driven home to me how difficult it
 is to keep track of "ownereship" of the disk space associated with
 LogExtentLists.  With the assignment operator and the common practice
 of copying extent lists, it is not unusual to have the same extent in
 more than one extent list at the same time.  The difficulty comes in
 determining which extent list has the responsibility for deallocating
 the disk space ("ownership" of the disk space, if you will).  Its
 clear to me that this must be decided at a level above the extent
 lists themselves.  I've gone to fairly extensive lengths in my EA
 implementaion to ensure that no disk space gets lost or doubly
 deallocated.
 
 As an alternative way of looking at this, could there be some sort of
 reference count underlying every LogExtent, that counts LogExtent
 objects that refer to it?  The LogExtent class could have a
 "deallocate" method that would simply set a mark.  When the last
 LogExtent object is destroyed and the reference count goes to zero,
 the disk space could be deallocated if the mark is set.

----------------------------------------------------------------

Terminology for ICBs and Nodes is mixed

We should ban the 'ICBAddr' lingo from the UDF Object Framework, and
make all methods (and data members) consistent -- We should use
'NodeAddr' instead.

----------------------------------------------------------------

TableSpaceResource is not tested

The srTest.cpp program COULD use an ISOSpaceResource or
TableSpaceResource, but currently, it does not. Right now, it only
tests the LELSpaceResource. To beef it up to test an ISOSR, it would
likely only have to do some loopback through its on-disk structures

----------------------------------------------------------------

PathElementList does not support automatic translation to
PathComponentList.

In the spirit of the other Objects in the Framework, this should
support some method(s) to go to ISO form and back, just like the
DirList object, except it would not have to support paging.

----------------------------------------------------------------
Loose end in Node::toDisk()

This needs Charley's review to resolve.

SAI reports:

There was a logic error in Node::toDisk() that would cause it to release all
AED space.  Notice the call to ::freeUnusedMetaDataExtents_() at the end of
this method.  The parameter numAEDsWritten was never modified in the body of
the ::toDisk() method, so it was always zero.  ::freeUnusedMetaDataExtents_()
interprets this as a special-case condition and frees ALL meta data extents. 
Upon further inspection, we found that the AEDWriter::toDisk() method
actually contains the code to do this, so this call was not necessary.  The
code in AEDWriter::toDisk() was disabled with a comment indicating that it
was not known if it was needed.  We enabled the code and have not noticed any
problems, but you should probably get the full story from Charlie before
enabling this code permanently.


----------------------------------------------------------------
Loose end in LogExtentList

SAI Reports:

I also added a small method to the LogExtentList class called ::collapse(). 
This function combines contiguous any contiguous extents in the list.  We are
not currently using this method in our code so you are free to remove it if
you want.  It may still be useful in the future however, although we will
probably look into using the PackedExtentList class now that it is fully
implemented.


----------------------------------------------------------------
Some methods should be made non-inline

SAI reports:

While going through the code, I found a number of inline methods that would
be better if moved into the source modules.  The Borland compiler does not
seem to be particularly intellegent at determining what functions are
suitable for inlining.  Some of these functions use static strings, while
others are just too long to be inlined.  Static strings consume a portion of
the limited (64K) static variable space each time the method is used when
inlined, but only consume enough space for one incarnation of the string when
the function is moved out-of-line.  As for size, I figured anything larger
than about six lines should probably be moved to the source module, since the
few extra cycles needed to call the out-of-line function would likely be
negligable in proportion to the processing time consumed in the function
itself.  The inline functions I identified as candidates for moving to the
source modules are as follows:

MasterSpaceResource::error()
MasterSpaceResource::initFromDisk()
MasterSpaceResource::initWithNewSpace()
MasterSpaceResource::syncToDiskUsingSR()
AEDWriter::getState()
Node::getState()
Node::error()
Node::ISOError()
DirList::free()
DirList::at()  (2)
PackedTAC::fileType()
PackedTAC::setFileCharacteristics()
PackedTAC::appendFileCharacteristics()
PackedTAC::setAllPermissions()
PackedTAC::appendAllPermissions()
Attributes::setOtherInfo()
Attributes::appendOtherInfo()
Attributes::appendUnixMode()
Attributes::appendUINT16Bits()
Attributes::appendFileType()
Attributes::appendAttributes()
Attributes::setAttributes()

----------------------------------------------------------------
SR error codes are inconsistent

SAI reports:

We also need to standardize the error return codes for all space resource
objects.  Some of the codes identify errors or conditions unique to a
particual implementation.  Other codes (i.e. insufficient space) represent
error return codes that could be returned by any implementation.  These
common codes should be standardized between the BitmapSpaceResource,
TableSpaceResource, and MasterSpaceResource so that users of the space
resource classes to not have to test for multiple manifestations of the same
error condition.

----------------------------------------------------------------

AttrTest problems!

These problems from attrTest may NOT apply any longer. They were run
by Mountain Optec on the pre-release code. I suspect that the
resolution of the purify bugs actually fixed these.

Questions:
- Were these from the Borland bounds-checking infrastructure?
- Were these from the debug version of Tools.h++?
- Do they still occur?

>From Ron Stawicki:
------------
"Attrtest.res" is the console output from running "attrtest"; it emitted a
number of error messages, and hence the reason for attachment as a file.
Also had a throw exception which traced to lines #311/#554/#656
"originalEntry = entry"
------------
Dave, the following represent the test results; also, in my last
E-Mail, I included the results of a throw exception using TD32
stack/line trace; if you don't have that, then keep me posted; the
following results were listed before the exception:


in Attributes::operator==() diffs is 7
attribuid 0xffffffff gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links 0
1---..---------- ---------------- 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 
ERROR: Could not set uid to complement in testNonBitAttributes().

ERROR: Could not restore uid from complement in testNonBitAttributes().
in Attributes::operator==() diffs is 7
attribuid 0x0 gid 0xffffffff times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links 0
1---..---------- ---------------- 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

ERROR: Could not set gid to complement in testNonBitAttributes().

ERROR: Could not restore gid from complement in testNonBitAttributes().
in Attributes::operator==() diffs is 7
attribuid 0x0 gid 0x0 times 0xce758458 0x318a7ba8 0x318a7ba9 links 0
1---..---------- ---------------- 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

ERROR: Could not set accessTime to complement in testNonBitAttributes().

ERROR: Could not restore accessTime from complement in testNonBitAttributes().
in Attributes::operator==() diffs is 7
attribuid 0x0 gid 0x0 times 0x318a7ba7 0xce758457 0x318a7ba9 links 0
1---..---------- ---------------- 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

ERROR: Could not set modificationTime to complement in testNonBitAttributes().

ERROR: Could not restore modificationTime from complement in
testNonBitAttributes().
in Attributes::operator==() diffs is 7
attribuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0xce758456 links 0
1---..---------- ---------------- 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

ERROR: Could not set uid attributeTime complement in testNonBitAttributes().

ERROR: Could not restore attributeTime from complement in
testNonBitAttributes().
in Attributes::operator==() diffs is 7
attribuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links 65535
1---..---------- ---------------- 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

ERROR: Could not set linkCount to complement in testNonBitAttributes().

ERROR: Could not restore linkCount from complement in testNonBitAttributes().
in Attributes::operator==() diffs is 6
attribuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links 0
1---..---UGK---- ---RWX--RWX--RWX 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

ERROR: Could not set unixMode to complement in testNonBitAttributes().

ERROR: Could not restore unixMode from complement in testNonBitAttributes().
in Attributes::operator==() diffs is 7
attribuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links 0
----..---------- ---------------- 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

ERROR: Could not set fileType to file_Unspecified in testNonBitAttributes().

ERROR: Could not restore fileType from file_Unspecified in
testNonBitAttributes().
in Attributes::operator==() diffs is 7
attribuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links 0
1111..---------- ---------------- 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

ERROR: Could not set fileType to invalid type in testNonBitAttributes().

ERROR: Could not restore fileType from invalid type in testNonBitAttributes().
in Attributes::operator==() diffs is 0
attribuid 0xffffffff gid 0xffffffff times 0xce758458 0xce758457 0xce758456
links 65535 ----..---UGK---- ---RWX--RWX--RWX 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

ERROR: Could not change state with all attributes in testNonBitAttributes().

ERROR: Attribute collision:  could not restore original state in
testNonBitAttributes().
Attributes test FAILED in testAttributes() [testNonBitAttributes()]

ERROR in Attributes::toFileEntry():  Read from Write failure.
attribuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links 0
1---..---------- ---------------- 
verifyAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 
in Attributes::operator==() diffs is 7
attribuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links 0
1---..D--------- ---------------- 
otherAttributesuid 0x0 gid 0x0 times 0x318a7ba7 0x318a7ba8 0x318a7ba9 links
0 1---..---------- ---------------- 

----------------------------------------------------------------

Currently, no testing is done on TableSpaceResource

Only the LELSpaceResource is tested. The vulnerability here is that
the to/fromISO() does not work properly.

----------------------------------------------------------------

lelTest is incestuous

Concept is flakey, in that it uses an SR to test LELs, and the
current SR is based upon LELs. This could work OK as long as we use
a BitmapSpaceResource, which has already been tested. However, it
requires an on-disk representation, and this may require that the
test be altered.

Perhaps the test should be rewritten to use an on-disk SR, of
either variety. Perhaps it could simply use one already on the
disk, in which case it could use the MasterSpaceResource.

----------------------------------------------------------------

BitmapTest has not been turned on.

This may work just fine (and apparently does on SAI's platform), but
we have not tried it here.

----------------------------------------------------------------

Error checking is not generally performed.

The error handling scheme we defined for the objects must be
rigorously followed. It is clear at least from the tests, that the
errors are not checked.

First priority has to be to make sure that this is followed in the
objects we ship, but the next priority has to be to make sure the
tests all do so as well.

For the tests, this includes the reporting of errors as well. Are
they all checked, and are they all reported via a consistent path
to the user?

----------------------------------------------------------------

newsrTst is questionably-functional

Right now, the display function is not implemented. This is because
it originally simply printed out portions of the bitmap, and the
bitmap is no longer used internally. The display function should be
re-implemented in order to allow the different SRs to be
interactively tested.

In order to support this, it might make sense for all SRs to
support some inspection methods, such that users may inquire about
specific blocks and whether or not they are currently
available. This COULD also be propagated into another allocation
method, such that users would request a specific extent or extent
list, and it would allocate it or them if possible.

----------------------------------------------------------------

All inline documentation needs thorough review.

This applies to ALL the ss code. Perhaps this only needs to be clean
for all of the public objects (and their public methods).

----------------------------------------------------------------

All UDF compliance issues should be documented.

Origination Only:

1. Hazards, or where user MUST know something about the format and is
   not protected against doing something in ignorance which makes it
   non-UDF.
2. Otherwise, no known limitations.

Receiving Only:

1. Any assumptions made inside of SingleSurfaceVolume::fromISO()?
2. Basically, has been designed to handle all cases. We may have
   missed a few, but it should mostly be there...
...
Others???

Origination and Receiving
1. No support for 64-bit data types
2. No support for 16-bit Unicode
3. WORM
4. Multi-volume

