xorriso: listing files+offsets in an ISO9660 image w/o RockRidge

[Jonathan Dowland]

Hi,

I'm trying to map files within ISO9660 images to block offsets within the
image. This is to try and determine which files are impacted by damaged or
missing blocks in the images.

These are all images of home made CD-rs and DVD-Rs from over the last 17 or so
years. I am importing them via ddrescue, so I have a log file of which blocks
have problems. The images generally have Joliet records, but most do not have
RockRidge records. The contents of the images can be successfully listed via
"isoinfo -lJ -i infile.iso", amongst other ways.

xorriso was suggested to me as a tool that might list the block offsets
too. I've tried variations on the following command:

xorriso -indev disk.iso -rockridge off -error_behavior image_loading best_effort -abort_on NEVER -find . -exec report_lba

But it seems to always complain about missing RR records:

> xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.
> xorriso : NOTE : Loading ISO image tree from LBA 0
> libisofs: SORRY : Damaged RR/SUSP information.
> libisofs: FAILURE : Wrong or damaged Rock Ridge entry
> xorriso : FAILURE : Cannot read ISO image tree
> xorriso : HINT : You might get a partial or altered ISO image tree by option -error_behavior 'image_loading' 'best_effort' if -abort_on is set to be tolerant enough.
> xorriso : NOTE : Tolerated problem event of severity 'FAILURE'
> Report layout: xt , Startlba , Blocks , Filesize , ISO image path
> xorriso : FAILURE : No ISO image present. No -dev, -indev, or -outdev selected.
> xorriso : NOTE : Tolerated problem event of severity 'FAILURE'
> xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FAILURE

This is with xorriso=1.3.2-1.1 from jessie. This happens even with images which
isoinfo claims have RR records, and which were 100% successfully recovered with
no bad blocks.

Can anyone suggest whether I am using xorriso wrong, or another tool to achieve
the same result?


Thanks,

--
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[Thomas Schmitt]

Hi,

your mail headers do not contain "LDO_SUBSCRIBER", so i Cc: you.

Jonathan Dowland wrote:
> [xorriso] seems to always complain about missing RR records:
> [...]

> xorriso -indev disk.iso -rockridge off -error_behavior image_loading
best_effort -abort_on NEVER -find . -exec report_lba

> libisofs: SORRY : Damaged RR/SUSP information.

It is probably not about the "RR" records of Rock Ridge, but generally
about the structure of System Use Protocol and its payload Rock Ridge.
I have to investigate under which conditions this error message is
emitted.

Option -rockridge controls production of ISOs.
The command not to use Rock Ridge while reading would be

-read_fs norock

but it was introduced only with xorriso-1.4.2.
You could try current GNU xorriso tarball
https://www.gnu.org/software/xorriso/xorriso-1.4.6.tar.gz
Its README has
tar xzf xorriso-1.4.6.tar.gz
cd xorriso-1.4.6
./configure --prefix=/usr
make
which should give you the executable binary
./xorriso/xorriso

(It is of course yet unclear whether -read_fs "norock" will help at all.)


Can you tell by which program you created the content of the media ?


Have a nice day :)

Thomas

[Thomas Schmitt]

Hi,

it looks like

-read_fs norock

with xorriso >= 1.4.2 gives hope to circumvent the error message.
It will go for the Joliet tree, if present, as would do "isoinfo -J".

If you want the dull ISO names in any case: -read_fs ecma119

--------------------------------------------------------------------

The error message "Damaged RR/SUSP information" is issued if the
chain of SUSP entries, which are attached to a ISO 9660 directory entry,
leads to an alleged chain member of length 0.
This would lead to an endless cycle when reading.

Hard to say what happened to your SUSP and Rock Ridge data. They form
a chain of linked records, which begins at the ISO 9660 directory entry
of a file. If it exceeds the maximum size of a directory record, then
the chain points to a Continuation Area, where its further entries are
stored.
Let's hope that the ISO 9660 tree is sane and that the bad entry is
in the Continuation Area. Or that there is a sane Joliet tree.

I would be interested to examine such an ISO, if privacy permits.

[Thomas Schmitt]

Hi,

regrettably the ban on reading Rock Ridge gets not into effect before
the attempt to read the SUSP entries of the root directory record.
So if that chain is damaged, then one would have to hack the source code:

-------------------------------------------------------------------------
--- libisofs/fs_image.c 2016-07-22 14:03:51 +0000
+++ libisofs/fs_image.c 2016-11-09 14:02:17 +0000
@@ -3017,15 +3017,14 @@
} while (buffer[0] != 255);

/* 4. check if RR extensions are being used */
- ret = read_root_susp_entries(data, data->pvd_root_block);
- if (ret < 0) {
- goto fs_cleanup;
- }
-
- /* user doesn't want to read RR extensions */
if (opts->norock) {
+ /* user doesn't want to read RR extensions */
data->rr = RR_EXT_NO;
} else {
+ ret = read_root_susp_entries(data, data->pvd_root_block);
+ if (ret < 0) {
+ goto fs_cleanup;
+ }
data->rr = data->rr_version;
}

-------------------------------------------------------------------------

After this change, the code which triggered the error message is not
reached any more, if Rock Ridge reading is disabled.

[Jonathan Dowland]

Partially answering my own question, "iso-info" from the libcdio-utils
package prints out the Logical Sector Number for files which is probably
what I need, at least it can be translated into the Logical Block Address,
I just need to figure out mapping the numbers from ddrescue's log files
into that space (offset for TOC etc.)

[Jonathan Dowland]

Hi Thomas, thanks for replying!

On Wed, Nov 09, 2016 at 02:02:48PM +0100, Thomas Schmitt wrote:
> your mail headers do not contain "LDO_SUBSCRIBER", so i Cc: you.

I've never heard of LDO_SUBSCRIBER, but I am subscribed - no need to CC
me. (I put something like that in my signature to make things clear, but
I guess most people don't get that far)

> Jonathan Dowland wrote:
> It is probably not about the "RR" records of Rock Ridge, but generally
> about the structure of System Use Protocol and its payload Rock Ridge.
> I have to investigate under which conditions this error message is
> emitted.

I see, thanks.

> Option -rockridge controls production of ISOs.
> The command not to use Rock Ridge while reading would be
>
> -read_fs norock
>
> but it was introduced only with xorriso-1.4.2.
> You could try current GNU xorriso tarball
> https://www.gnu.org/software/xorriso/xorriso-1.4.6.tar.gz

I'll try everything with 1.4.6 (more details on what I will try in the
other replies)

> Can you tell by which program you created the content of the media ?

A mixture - I'm importing home made CD-rs and DVD-Rs, burned by myself and
family and friends over a period of 18 years or so; so lots of different
platforms, and burning software. I've got 45 imported ISOs so far, with
hundreds more to do.

I'll try the following command with both my current xorriso version and 1.4.6,
against all of my currently imported ISOs, and report back what my results
are:

xorriso -indev $ISO -error_behavior image_loading best_effort

-abort_on NEVER -find . -exec report_lba

I'll also try -norock with 1.4.6 for any images that fail to see if that
makes any difference.

[Jonathan Dowland]

On Wed, Nov 09, 2016 at 02:29:25PM +0100, Thomas Schmitt wrote:
> I would be interested to examine such an ISO, if privacy permits.

Thanks for the offer!

Once I've narrowed down which of my ISOs suffer this problem, I'll see
which are not too private, some are basically just "Downloads" folders
from a long time ago, and probably just DOOM PWADs...

[Jonathan Dowland]

On Thu, Nov 10, 2016 at 11:35:02AM +0000, Jonathan Dowland wrote:
> I'll try the following command with both my current xorriso version and 1.4.6,
> against all of my currently imported ISOs, and report back what my results
> are:

With 1.3.2, at least, only 20/45 of my ISOs fail; the Application labels for them
are

4 Application:
1 Application:
1 Application: EASY CD CREATOR 5.3 (010) COPYRIGHT (C) 1999-2003 ROXIO, INC.
1 Application: Nero - Burning ROM
2 Application: NERO BURNING ROM
4 Application: NERO___BURNING_ROM
1 Application: TOAST ISO 9660 BUILDER COPYRIGHT (C) 1997 ADAPTEC, INC. - HAVE A NICE DAY
2 Application: 䍄啄䘠䙩汥祳瑥洠䅤慰瑥挠䥮挀††††††††††††††††††††††††††††††††††††††††††††††††

The first one is completely empty labels. The second is roughly 64 whitespace
characters.

That last one, I recognise those ISOs as my very earliest. They were burned by
a friend in around 1998 or 1999, so I don't know exactly what hardware or
software he used but it was definitely a Windows machine. I doubt the label is
really in Chinese, I'd imagine that's probably just the raw bytes being
interpreted in Unicode by my terminal.

The penultimate one was burned using a classic Mac of some sort.

All the Nero ones would have been burned on Windows machines.

Labels extracted with iso-info -i "$ISO"

[Thomas Schmitt]

Hi,

Jonathan Dowland wrote:
> 4 Application:
> 1 Application:
> ...

> The first one is completely empty labels. The second is roughly 64
> whitespace characters.

Looks like an interesting collection.
It would be nice if libisofs could exercise with it.

I am in the process of testing a xorriso-1.4.7 snapshot which is supposed
not to read the root node's SUSP entries if -read_fs is set to "norock".
(Actually the snapshot is about a bug in mkisofs emulation.)
Will give you a node when it is uploaded.


I let xorriso put its hallmark into the field "Preparer Identifier".
The description of both fields in ECMA-119 specs does not look like
"Application Identifier" is the right place.


> ...
> 2 Application: [pseudo chinese]
> ...

> I doubt the label is really in Chinese,

Possibly 2-byte character set UCS-2 / UTF-16.

[Thomas Schmitt]

Hi,

i have now uploaded
http://www.gnu.org/software/xorriso/xorriso-1.4.7.tar.gz
for testing of improved xorriso command -read_fs "norock".

[Thomas Schmitt]

Hi,

two hours ago, i sent the mail below as reply to
https://lists.debian.org/debian-user/2016/11/msg00355.html
Subject line was:
LDO_SUBSCRIBER, was Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge
Date: Thu, 10 Nov 2016 12:59:10 +0100

But it did not arrive in my mailbox and does not show up in the archive.

So another try. This time with the thread's original subject line.

--------------------------------------------------------------------

Jonathan Dowland wrote:
> I've never heard of LDO_SUBSCRIBER, but I am subscribed

My mails (and those of most other regular posters) have it in their
X-Spam-Status when they arrive in my mailbox something like:

X-Spam-Status: No, score=-16.9 required=4.0 tests=FOURLA,FREEMAIL_FROM,
FVGT_m_MULTI_ODD,LDOSUBSCRIBER,LDO_WHITELIST,RCVD_IN_DNSWL_LOW,
RCVD_IN_MSPIKE_H2,RCVD_IN_SORBS_SPAM,
RP_MATCHES_RCVD autolearn=unavailable
autolearn_force=no version=3.4.0

The word "LDOSUBSCRIBER" seems to be the indication for a sunscribed
sender.

The headers in mails from you look like:

X-Spam-Status: No, score=-10.0 required=4.0
tests=HEADER_FROM_DIFFERENT_DOMAINS,LDO_WHITELIST,PGPSIGNATURE,
RCVD_IN_DNSWL_NONE autolearn=unavailable autolearn_force=no
version=3.4.0

My best theory for now is that your @debian.org sender address is processed
differently from other @domain addresses.

> (I put something like that in my signature to make things clear, but
> I guess most people don't get that far)

At least not when technical eagerness has taken over. :))

[Jonathan Dowland]

On Thu, Nov 10, 2016 at 03:21:42PM +0100, Thomas Schmitt wrote:
> My mails (and those of most other regular posters) have it in their
> X-Spam-Status when they arrive in my mailbox something like:

...

> The word "LDOSUBSCRIBER" seems to be the indication for a sunscribed
> sender.

...

> My best theory for now is that your @debian.org sender address is processed
> differently from other @domain addresses.

Ah yes, I see. @debian.org is forward-only: it forwards to a private address
of mine, from which I send, although the From: is set to @debian.org (you can
see the semi-private address in my Envelope-From). I'm going to hazard a guess
that the list server's spamassassin is marking mails as LDOSUBSCRIBER if the
envelope-from (rather than From: header) matches an address that is known to be
subscribed (which my semi-private address is not).

[Brian]

On Thu 10 Nov 2016 at 15:21:42 +0100, Thomas Schmitt wrote:

> Hi,
>
> two hours ago, i sent the mail below as reply to
> https://lists.debian.org/debian-user/2016/11/msg00355.html
> Subject line was:
> LDO_SUBSCRIBER, was Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge
> Date: Thu, 10 Nov 2016 12:59:10 +0100
>
> But it did not arrive in my mailbox and does not show up in the archive.

It didn't arive here either.

> So another try. This time with the thread's original subject line.
>
> --------------------------------------------------------------------
>
> Jonathan Dowland wrote:
> > I've never heard of LDO_SUBSCRIBER, but I am subscribed
>
> My mails (and those of most other regular posters) have it in their
> X-Spam-Status when they arrive in my mailbox something like:
>
> X-Spam-Status: No, score=-16.9 required=4.0 tests=FOURLA,FREEMAIL_FROM,
> FVGT_m_MULTI_ODD,LDOSUBSCRIBER,LDO_WHITELIST,RCVD_IN_DNSWL_LOW,
> RCVD_IN_MSPIKE_H2,RCVD_IN_SORBS_SPAM,
> RP_MATCHES_RCVD autolearn=unavailable
> autolearn_force=no version=3.4.0
>
> The word "LDOSUBSCRIBER" seems to be the indication for a sunscribed
> sender.

A reasonable assumption. However, a lack of LDOSUBSCRIBER tells you
nothing about whether the sender is a subscriber to the list or not.

--
Brian.

[Jonathan Dowland]

On Thu, Nov 10, 2016 at 11:56:36AM +0000, Jonathan Dowland wrote:
> On Thu, Nov 10, 2016 at 11:35:02AM +0000, Jonathan Dowland wrote:
> > I'll try the following command with both my current xorriso version and 1.4.6,
> > against all of my currently imported ISOs, and report back what my results
> > are:
>
> With 1.3.2, at least, only 20/45 of my ISOs fail; the Application labels for them
> are

Interestingly 1.4.7 can read one more of these ISOs, leaving 19 bad.

With 1.3.2 and this ISO in particular, it said

libisofs: SORRY : Mandatory Rock Ridge PX entry is not present or it contains invalid values.

with 1.4.7, I get a few warnings

...
libisofs: WARNING : Sum of resolved file name collisions: 159
Boot record : (system area only) , not-recognized APM
Media summary: 1 session, 345484 data blocks, 675m data, 72.2g free
...

but it does enumerate the files in the image.

isoinfo(1) from genisoimage package gives the following metadata. This was almost certainly
burned on a Windows machine albeit with iPhoto or iTunes or something

CD-ROM is in ISO 9660 format
System id: APPLE COMPUTER, INC., TYPE: 0002
Volume id: IPHOTOARCHIV_240206
Volume set id:
Publisher id:
Data preparer id:
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 345484
Joliet with UCS level 1 found
Rock Ridge signatures version 1 found

[Thomas Schmitt]

Hi,

> Interestingly 1.4.7 can read one more of these ISOs, leaving 19 bad.

Was that already with -read_fs "norock" ?

If so: Do you still see the error message
"Damaged RR/SUSP information."
?

> With 1.3.2 and this ISO in particular, it said
> libisofs: SORRY : Mandatory Rock Ridge PX entry is not present or it
> contains invalid values.

The error message still exists in 1.4.7. Somehow it must have avoided it.

> with 1.4.7, I get a few warnings

> libisofs: WARNING : Sum of resolved file name collisions: 159

Name collisions should not occur in any filesystem tree.
There is a limit of 255 characters per path component. Longer names get
truncated and could then collide. But that's very unlikely because the
truncated names contain a string with the MD5 of the untruncated name.

Are there preceeding warnings of form

File name collision resolved with %s . Now: %s

?
The path and file name inserted into "%s" would be of interest.

> Boot record : (system area only) , not-recognized APM

That's not a warning but a status summary:
"(system area only)" = No El Torito boot record is present.
"not-recognized" = none of the known hard disk boot sectors was recognized.
"APM" = an Apple Partition Map was found.

You might get more details about the APM with

xorriso -indev ... -report_system_area plain

> System id: APPLE COMPUTER, INC., TYPE: 0002
> Volume id: IPHOTOARCHIV_240206

Might "240206" be a date stamp ? (24 Feb 2006 ?)

[Jonathan Dowland]

On Thu, Nov 10, 2016 at 07:39:22PM +0100, Thomas Schmitt wrote:
> > Interestingly 1.4.7 can read one more of these ISOs, leaving 19 bad.
>
> Was that already with -read_fs "norock" ?

No, I didn't try that yet; I'll try that when I next take a look (probably
Monday). Thanks for the suggestion!

> Name collisions should not occur in any filesystem tree.
> There is a limit of 255 characters per path component. Longer names get
> truncated and could then collide. But that's very unlikely because the
> truncated names contain a string with the MD5 of the untruncated name.
>
> Are there preceeding warnings of form
>
> File name collision resolved with %s . Now: %s
>
> ?
> The path and file name inserted into "%s" would be of interest.

Yep - I'll put a full log of the output up somewhere and reply with it.
(I'm hoping to be able to either provide some interesting ISOs or zero
the file contents and provide the result or truncate after the TOC,
depending on what is one the discs!)

> Might "240206" be a date stamp ? (24 Feb 2006 ?)

Yep quite likely. That means I didn't burn it, which isn't that
surprising I suppose, because I can't remember burning it :) (stuff
of my Wife's)

> Have a nice day :)

you too!

[Jonathan Dowland]

On Fri, Nov 18, 2016 at 03:29:54PM +0000, Jonathan Dowland wrote:
> I'm wondering if my hand-built modern xorriso is linking against my old system libisofs.
> I am doing some investigation.

I can't see any .so files in my xorriso build directory, but ldd does not show this xorriso
binding against my system libisofs. Is the default to statically link? Or is it loaded at
run time?

[Jonathan Dowland]

On Thu, Nov 10, 2016 at 07:39:22PM +0100, Thomas Schmitt wrote:

> Hi,
>
> > Interestingly 1.4.7 can read one more of these ISOs, leaving 19 bad.
>
> Was that already with -read_fs "norock" ?

Just retried: alas, no difference, same number of unreadable ISOs (19), same
output, here's the full output of one of them,

GNU xorriso 1.4.7 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0

libisofs: SORRY : Damaged RR/SUSP information.

libisofs: FAILURE : Wrong or damaged Rock Ridge entry
xorriso : FAILURE : Cannot read ISO image tree
xorriso : HINT : You might get a partial or altered ISO image tree by option -error_behavior 'image_loading' 'best_effort' if -abort_on is set to be tolerant enough.
xorriso : NOTE : Tolerated problem event of severity 'FAILURE'
Report layout: xt , Startlba , Blocks , Filesize , ISO image path
xorriso : FAILURE : No ISO image present. No -dev, -indev, or -outdev selected.
xorriso : NOTE : Tolerated problem event of severity 'FAILURE'
xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FAILURE

This particular image has the first 0x046B1000 bytes (~70 MiB?) read correctly by
ddrescue so I believe that means the TOC must be intact. isoinfo/genisoimage and
iso-info/libcdio-utils can read it ok. I see basically the same output for all the
failing ISOs.

isoinfo reports

isoinfo: Warning: Joliet escape sequence uses illegal space at offset 3

iso-info reports a line like the following for each directory

++ WARN: XA signature not found in ISO9660's system use area; ignoring XA attributes for this file entry.

This might not have been a great example, because I can't share the contents of the ISO
(old emails and ICQ logs). Looking at my list, I have four ISOs which are recordings
from TV made with a DVD writer appliance, they all have volume labels 'SONATA_VOLUME',
I can share them with you privately.

I also have a rip of a commercial CD that xorriso is complaining about, Paint Shop Pro 7
for Windows. Again isoinfo and iso-info are happy with it. What's *really* interesting
about this one is, despite it being a silver disc commercial CD that I bought, the volume
metadata is

CD-ROM is in ISO 9660 format
System id:

Volume id: IEPSP704A_AE

Volume set id:
Publisher id:
Data preparer id:

Application id: NERO___BURNING_ROM

Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048

Volume size is: 147702
Joliet with UCS level 3 found
NO Rock Ridge present

I suppose the master that was sent to the duplicator was made this way.

For some reason I am missing the ddrescue log file for this rip, which is frustrating, I will
re-rip it next time I'm at my office.

> If so: Do you still see the error message
> "Damaged RR/SUSP information."

I'm afraid so yes.

I'm wondering if my hand-built modern xorriso is linking against my old system libisofs.
I am doing some investigation.

[Thomas Schmitt]

Hi,

i wrote:
> > Was that already with -read_fs "norock" ?

Jonathan Dowland wrote:
> Just retried: alas, no difference
> ...

> libisofs: SORRY : Damaged RR/SUSP information.

It should not even get near to that error message.
Grrr ...

> I'm wondering if my hand-built modern xorriso is linking against my old
> system libisofs.

If you got the GNU xorriso tarball, then it is not linked dynamically
with installed libisofs.so but rather statically with its own copy of
libisofs.

In the build directory

$ xorriso/xorriso -version

should say:

GNU xorriso 1.4.7 : RockRidge filesystem manipulator, libburnia project.

...
xorriso version : 1.4.7
Version timestamp : 2016.11.10.134753

Please check in this directory whether file
libisofs/fs_image.c
contains the bug fix:

--- libisofs/fs_image.c 2016-07-22 14:03:51 +0000

+++ libisofs/fs_image.c 2016-11-13 09:23:36 +0000

@@ -3017,15 +3017,14 @@
} while (buffer[0] != 255);

/* 4. check if RR extensions are being used */
- ret = read_root_susp_entries(data, data->pvd_root_block);
- if (ret < 0) {
- goto fs_cleanup;
- }
-
- /* user doesn't want to read RR extensions */
if (opts->norock) {
+ /* user doesn't want to read RR extensions */
data->rr = RR_EXT_NO;
} else {
+ ret = read_root_susp_entries(data, data->pvd_root_block);
+ if (ret < 0) {
+ goto fs_cleanup;
+ }
data->rr = data->rr_version;
}

Online:
https://dev.lovelyhq.com/libburnia/libisofs/commit/c51efce8d1c6f076721075584af336bc4d3ba104

If the "+" variant looks like being in effect, then please let gdb check
how the Rock Ridge read attempt sneaks in. Set two break points:

One at fs_image.c line 3024:

ret = read_root_susp_entries(data, data->pvd_root_block);

The other at rockridge_read.c line 111:
iso_msg_submit(iter->msgid, ISO_WRONG_RR, 0,
"Damaged RR/SUSP information.");

So the gdb run shall look like

$ gdb xorriso/xorriso
(gdb) b fs_image.c:3024
(gdb) b rockridge_read.c:111
(gdb) r -read_fs norock -indev /path/to/your.iso

If it stops at one of the breakpoints, please do

(gdb) where

and report the output.
Then you can leave gdb by

(gdb) quit

If it still throws the error essage without stopping, then we have
to rethink and check for gremlins.

(It might be that i then ask you to remove two occurences of "-O2"
in the ./configure script, to re-build and re-run with gdb.)

> isoinfo reports
> isoinfo: Warning: Joliet escape sequence uses illegal space at offset 3
> iso-info reports a line like the following for each directory
> ++ WARN: XA signature not found in ISO9660's system use area; ignoring XA attributes for this file entry.

That's obviously Joliet woes. (Not only Rock Ridge can be awkward.)

> This might not have been a great example, because I can't share the contents
> of the ISO (old emails and ICQ logs).

Please mail me in private where i can download it.

> I have four ISOs which are recordings from TV made with a DVD writer
> appliance,

That's probably UDF filesystems. Interesting anayways.

Have a nice day :)

Thomas

[Jonathan Dowland]

On Fri, Nov 18, 2016 at 05:27:25PM +0100, Thomas Schmitt wrote:
> If you got the GNU xorriso tarball, then it is not linked dynamically
> with installed libisofs.so but rather statically with its own copy of
> libisofs.

OK, yup that's what I did.

> In the build directory
>
> $ xorriso/xorriso -version
>
> should say:
>
> GNU xorriso 1.4.7 : RockRidge filesystem manipulator, libburnia project.
> ...
> xorriso version : 1.4.7
> Version timestamp : 2016.11.10.134753

Yep

> Please check in this directory whether file
> libisofs/fs_image.c
> contains the bug fix:

Yes, the code corresponds to the patch being applied.

> If the "+" variant looks like being in effect, then please let gdb check
> how the Rock Ridge read attempt sneaks in. Set two break points:

Sure ok, I will have to try that a little later today or this week.

> > This might not have been a great example, because I can't share the contents
> > of the ISO (old emails and ICQ logs).
>
> Please mail me in private where i can download it.

Sorry, I can't share that image (but there are others I probably can).

> > I have four ISOs which are recordings from TV made with a DVD writer
> > appliance,
>
> That's probably UDF filesystems. Interesting anayways.

Good catch: you are right, they are. Are they interesting enough for me to
put them online somewhere?

[Thomas Schmitt]

Hi,

i wrote about video DVDs:

> > That's probably UDF filesystems. Interesting anayways.

Jonathan Dowland wrote:
> Good catch: you are right, they are. Are they interesting enough for me to
> put them online somewhere?

If they demonstrate the Rock Ridge read error despite -read_fs "norock",
then they might help to solve the riddle.

Else they could still be valuable for general research.

[Jonathan Dowland]

On Tue, Nov 22, 2016 at 09:46:16PM +0100, Thomas Schmitt wrote:
> If they demonstrate the Rock Ridge read error despite -read_fs "norock",
> then they might help to solve the riddle.

Yes the do. I'm just about to mail you privately with a URL to one.

[Jonathan Dowland]

On Fri, Nov 18, 2016 at 05:27:25PM +0100, Thomas Schmitt wrote:

> $ gdb xorriso/xorriso
> (gdb) b fs_image.c:3024
> (gdb) b rockridge_read.c:111
> (gdb) r -read_fs norock -indev /path/to/your.iso

Using the above and one of the UDF images that I am about to email you a URL to,
and the above, the process exits normally (w/o hitting breakpoints) and w/o
printing the RR error.

But digging into this a little, it seems to be an argument order issue.

works: -read_fs norock -indev ...
problems: -indev ... -read_fs norock

So running GDB but flipping the argument order from your example:

(gdb) r -indev /media/scratch/DVDrs/ballards_world.iso -read_fs norock
Starting program: /home/jon/git/xorriso-1.4.7/xorriso/xorriso -indev /media/scratch/DVDrs/ballards_world.iso -read_fs norock
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

GNU xorriso 1.4.7 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0

Breakpoint 1, iso_image_filesystem_new (src=<optimized out>, opts=0x820e50, msgid=<optimized out>, fs=0x7fffffffe000)
at libisofs/fs_image.c:3024

3024 ret = read_root_susp_entries(data, data->pvd_root_block);

> If it stops at one of the breakpoints, please do
>
> (gdb) where

(gdb) where
#0 iso_image_filesystem_new (src=<optimized out>, opts=0x820e50, msgid=<optimized out>, fs=0x7fffffffe000)
at libisofs/fs_image.c:3024
#1 0x00000000004a6401 in iso_image_import (image=0x1, src=0x800, src@entry=0x820e90, opts=0x0, features=0x0,
features@entry=0x7fffffffe140) at libisofs/fs_image.c:5703
#2 0x000000000048cf9f in isoburn_read_image (d=<optimized out>, read_opts=0x820d50, image=0x7fffffffe220)
at libisoburn/isofs_wrap.c:316
#3 0x000000000045912e in Xorriso_aquire_drive (xorriso=0x7ffff7e21010,
adr=0x800 <error: Cannot access memory at address 0x800>,
adr@entry=0x820210 "/media/scratch/DVDrs/ballards_world.iso", show_adr=show_adr@entry=0x0, flag=1)
at xorriso/drive_mgt.c:565
#4 0x000000000043e8c5 in Xorriso_option_dev (xorriso=0x7ffff7e21010, in_adr=<optimized out>, flag=<optimized out>)
at xorriso/opts_d_h.c:122
#5 0x0000000000431fc1 in Xorriso_interpreter (xorriso=0x7ffff7e21010, argc=5, argv=0x0, idx=0x7fffffffe424, flag=255,
flag@entry=2) at xorriso/parse_exec.c:1389
#6 0x0000000000403dd2 in main (argc=5, argv=0x820150) at xorriso/xorriso_main.c:265

[Thomas Schmitt]

Hi,

Jonathan Dowland wrote:
> But digging into this a little, it seems to be an argument order issue.

Yes, sequence matters. The arguments are commands like in a shell script,
not options like with program "ls".

There is command -x which lets xorriso sort the arguments in a sequence
that is most likely to do what would be desired by a user who is not
interested in a particular sequence.

> (gdb) r -indev /media/scratch/DVDrs/ballards_world.iso -read_fs norock

This first loads the ISO and then disables Rock Ridge reading.

-read_fs norock -indev /media/scratch/DVDrs/ballards_world.iso

or

-x -indev /media/scratch/DVDrs/ballards_world.iso -read_fs norock

are supposed to do better.

[Jonathan Dowland]

On Wed, Nov 23, 2016 at 03:40:22PM +0000, Jonathan Dowland wrote:
> But digging into this a little, it seems to be an argument order issue.

...and all of my ISOs now read fine without the RR warnings. I haven't double-checked
the docs, if you state that the argument order of -read_fs / -indev is important, then
this is just pilot error after all :-)

[Thomas Schmitt]

Hi,

Jonathan Dowland sent me the URL of a test image which demonstrates
the problem with reading ISO 9660 images not produced on Linux.


Indeed the problem appears when reading the Rock Ridge info of the
root directory. So xorriso-1.4.6 in Debian testing cannot avoid it.

The root directory record is at block 259. Its length is 40 bytes of
which 34 are occupied by ISO 9660 directory data. So 6 bytes stay free
for potential SUSP data. All 6 bytes are 0. So it is no SUSP.

Here libisofs makes a mistake:
When checking for the SUSP entry "SP" it accepts 0 potential SUSP bytes
or a SUSP-compliant entry. The case of non-SUSP extra bytes is not covered
and triggers the error message.

libisofs should have disabled Rock Ridge reading automatically rather than
bailing out.

I will now develop a remedy and use your ISO to test it.
Then i'll ask Jonathan to check it on xihis collection.