[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libcdio-devel] Rock Ridge deep directory support

From: Pete Batard
Subject: [Libcdio-devel] Rock Ridge deep directory support
Date: Sat, 30 May 2020 13:42:54 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]