Re: [Libcdio-devel] Rock Ridge deep directory support

[Rocky Bernstein]

Wow!

I will look and try the code when I get a chance.

Thanks!


On Sat, May 30, 2020 at 8:43 AM Pete Batard <pbatard@gmail.com> wrote:

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