[Libcdio-devel] Rock Ridge deep directory support

[Pete Batard]

Hi,

I have just completed my RR deep directory support proposal, which can 
be found in the new rr-deep-directory branch I just pushed.

Support for deep directory has been added in a transparent manner, so 
that, as long as an ISO image has been opened with 
ISO_EXTENSION_ROCK_RIDGE, no alteration of existing code should be needed.

Now, because deep directory entries work with a Child Link (CL) 
providing the LSN of an entry that usually resides in a Relocated Entry 
(RE) directory, such as 'rr_moved/', and thus on a completely different 
branch from the directory we are processing, we need to be able to 
traverse the ISO9660 tree from within get_rock_ridge_filename() to 
obtain the stat of the target, which means that we need to have access 
to the image/device source to be able to traverse it.

The result of that is that some calls have to be modified to take an 
extra image parameter. And to make matters a bit more complex, some of 
these calls were designed to process either an iso9660_t or a CdIo_t, so 
we need our processing to be generic enough to handle both.

However, we also need to toggle deep directory processing while we are 
traversing directories to prevent endless recursion as we enter 
get_rock_ridge_filename() again.

The solution to that is to modify the underlying iso9660_t and CdIo_t 
structures so that they start with a common header (which we define in 
cdio_private.h), where we can set a flag.

One we have all of the above, a deep directory search is performed as 
follows:
- A CL entry is encountered
- We create a duplicate of the CdIo_t or iso9660_t struct and set the 
CDIO_HEADER_FLAGS_DISABLE_RR_DD flag to indicate that we will not be 
processing deep directories during this lookup.
- We perform the LSN lookup with the duplicate, thus, when we get to 
_iso9660_dir_to_statbuf(), deep directory entries are processes as 
straight ISO9660 entries, resulting in the RE directories that were 
previously ignored being looked into, and CL links not being followed.
- Once we have the stat that is associated with the LSN entry, we use 
that in get_rock_ridge_filename().

Obviously, the reason we need to go through a duplicate, rather than 
just toggling the DISABLE_RR_DD flag in the original image, is because 
of concurrency. For instance, users might use a single p_iso to perform 
simultaneous lookups from different threads, so altering that single 
p_iso to disable DD lookup would be a bad idea.

You'll also notice that I added a new u_su_fields element to the Rock 
Ridge stat attributes, that reflect the Rock Ridge extensions applying 
to an entry (though, technically, some of the "extensions" we define are 
not actually Rock Ridge ones). The reason behind that is twofold:
1. I want to be able to report the use of deep directories in Rufus, 
which means I need to detect PL.
2. These might be needed for applications that end up not relying on 
_iso9660_dir_to_statbuf() to parse a Rock Ridge directory and therefore 
will need to perform deep directory processing themselves.

Speaking of 2., the current cd-info and dvd-info apps are like that, 
which is the reason why, if you try to use them against a deep directory 
image, you will only see the underlying ISO9660 structure. As a matter 
of fact, even as these apps are supposed to handle Rock Ridge, they seem 
to be missing a lot of code to properly do so. But with the new 
u_su_fields, they could be modified to perform the CL lookup. I am not 
planning to do any of that though, as I've spent way more time on this 
whole deep directory endeavour as I'd have liked, and I need to move on.

Now, with regards to the commits themselves:
- 0001 fixes unrelated warnings that I've been seeing when compiling and 
testing on Linux
- 0002 also fixes an issue we have with iso9660_open() where it is 
really iso9660_open_ext(..., ISO_EXTENSION_NONE), so using that call in 
something like testisorr.c should never have worked since it should have 
disabled RR altogether. And since I fixed the use or non use of 
ISO_EXTENSION_ROCK_RIDGE in my patch, this obviously needs to be 
addressed so that the tests can pass.
- 0003 Removes dead code we had in rock.c
- 0004 Adds the u_su_fields Rock Ridge System Use field to 
iso_rock_statbuf_t, and fixes a couple other small Rock Ridge related 
issues (warn about SF files and fix the CL and PL structs). Even as we 
will make use of these attributes for deep directories, this patch is 
not directly related to adding deep directory support.
- 0005 Adds proper deep directory support. And yeah, I don't having to 
add an extern reference for iso9660_dd_find_lsn() in rock.h, but extern 
works fine and creating a new internal header for just a single call 
looked like overkill, as this call should be internal and there is no 
good existing header where it would fit.
- 0006 Adds a deep directory test. The test image is designed to have 
more than one deep directory level.

Feel free to review and test and let me know if you see any issues.

Regards,

/Pete