[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 |
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
- [Libcdio-devel] Rock Ridge deep directory support,
Pete Batard <=