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