Hi,
I recently found that some Rock Ridge ISOs processed using the latest
libcdio were mangling file names. Instead names being returned with the
expected Rock Ridge data, I found that I got something like
"FILENAME.EXT;1" from libcdio, which created issues with my downstream
code. I was also able to confirm that this behaviour wasn't happening
with some older versions of the library.
Looking further into this, I identified that the commit that brought
this change was 8b96bd3f ("Guard against malformed rockridge iso" from
2015.05.08), where the Rock Ridge SUSPs are now being checked against a
set of supported extensions, and that the issue happened if the ISO
being processed (such as kali-linux-2017.1-amd64.iso) was using the
nonstandard Rock Ridge extension 'AL'.
Obviously, as per the switch statement around line 172 of rock.c,
libcdio does not currently recognize 'AL' as a valid Rock Ridge
extension (whereas previous code just let it pass through), hence the
problem observed.
Digging further into this still, I eventually managed to determine that
the 'AL' Rock Ridge extension is something that the libburnia people
(the developers behind libisofs & xorriso) introduced as part of their
custom "Arbitrary Attribute Interchange Protocol" or AAIP, which they
have documented at
https://dev.lovelyhq.com/libburnia/libisofs/blob/master/doc/susp_aaip_2_0.txt
From what I gather, they created AAIP along with the 'AL' generic
extension mostly in order to carry POSIX ACLs into an ISO 9660
filesystem. These can then get added to the Rock Ridge data with the
-acl option of xorriso.
My questions therefore are:
- Should libcdio add support for the 'AL' Rock Ridge extension?
- If so, is there anybody on this list willing to do it?
Regards,
/Pete
NB: There also
