Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #174416 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-09 12:30 +0100
    Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-09 14:10 +0100
      Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-09 14:40 +0100
        Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-09 15:20 +0100
        Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-10 12:40 +0100
      Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-10 12:40 +0100
        Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-10 13:00 +0100
          Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-10 13:30 +0100
            Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-10 15:10 +0100
          Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-10 17:40 +0100
            Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-10 19:50 +0100
              Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-11 22:20 +0100
              Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-18 16:40 +0100
              Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-18 16:40 +0100
                Re: orriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-18 17:30 +0100
                  Re: orriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-22 11:50 +0100
                    Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-22 21:50 +0100
                      Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-23 16:40 +0100
                  Re: orriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-23 16:50 +0100
                    Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-23 17:00 +0100
                      Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-23 19:40 +0100
                    Re: orriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-23 17:00 +0100
        Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-10 15:30 +0100
          Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-10 15:50 +0100
          Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Brian <ad44@cityscape.co.uk> - 2016-11-10 16:40 +0100
    Re: xorriso: listing files+offsets in an ISO9660 image w/o RockRidge Jonathan Dowland <jmtd@debian.org> - 2016-11-09 18:10 +0100

Page 1 of 2  [1] 2  Next page →

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

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [next] | [standalone]

#174417

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

[toc] | [prev] | [next] | [standalone]

#174419

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.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#174420

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.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#174459

[Multipart message — attachments visible in raw view] — view raw

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
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#174458

[Multipart message — attachments visible in raw view] — view raw

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
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#174461

[Multipart message — attachments visible in raw view] — view raw

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"

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

[toc] | [prev] | [next] | [standalone]

#174463

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.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#174467

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".


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#174480

[Multipart message — attachments visible in raw view] — view raw

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

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

[toc] | [prev] | [next] | [standalone]

#174483

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 ?)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#174535

[Multipart message — attachments visible in raw view] — view raw

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
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#174858

[Multipart message — attachments visible in raw view] — view raw

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
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#174859

[Multipart message — attachments visible in raw view] — view raw

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.

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

[toc] | [prev] | [next] | [standalone]

#174863 — Re: orriso: listing files+offsets in an ISO9660 image w/o RockRidge

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

[toc] | [prev] | [next] | [standalone]

#174994 — Re: orriso: listing files+offsets in an ISO9660 image w/o RockRidge

[Multipart message — attachments visible in raw view] — view raw

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?

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

[toc] | [prev] | [next] | [standalone]

#175013

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.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#175031

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#175032 — Re: orriso: listing files+offsets in an ISO9660 image w/o RockRidge

[Multipart message — attachments visible in raw view] — view raw

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


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

[toc] | [prev] | [next] | [standalone]

#175033

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.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web