libcdio-devel
[Top][All Lists]
Advanced

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

Re: [Libcdio-devel] Hindsight is 2020 - Let's sort multiextents at last


From: Thomas Schmitt
Subject: Re: [Libcdio-devel] Hindsight is 2020 - Let's sort multiextents at last
Date: Sat, 23 May 2020 15:41:09 +0200

Hi,

a first bug fix to test, possibly beautify, and commit in
pragmatic-multiextent-2020:

diff --git a/lib/iso9660/iso9660_fs.c b/lib/iso9660/iso9660_fs.c
index ed2d158..48e098f 100644
--- a/lib/iso9660/iso9660_fs.c
+++ b/lib/iso9660/iso9660_fs.c
@@ -844,7 +844,9 @@ _iso9660_dir_to_statbuf (iso9660_dir_t *p_iso9660_dir,
   {
     /* Check if this is the last part of a multiextent file */
     if (!first_extent) {
-      if (strcmp(p_stat->filename, &p_iso9660_dir->filename.str[1]) != 0) {
+      if (strlen(p_stat->filename) != i_fname ||
+          strncmp(p_stat->filename, &p_iso9660_dir->filename.str[1], i_fname)
+         != 0) {
        cdio_warn("Non consecutive multiextent file parts for '%s'",
                  p_stat->filename);
        goto fail;

=========================================================================

It's obviously my own bug, nevertheless i think Pete should operate git
when we both work together. :))

Testing

  src/iso-info -i "$isodir"/large.iso --iso9660

reports

  ++ WARN: Non consecutive multiextent file parts for 'LARGE_FILE.;1'

lib/iso9660/iso9660_fs.c has

      if (strcmp(p_stat->filename, &p_iso9660_dir->filename.str[1]) != 0) {
        cdio_warn("Non consecutive multiextent file parts for '%s'",

Inserting some cdio_warn() before the "if (strcmp " line
      cdio_warn("TS_DEBUG: '%s'", p_stat->filename);
      cdio_warn("TS_DEBUG: '%s'", &p_iso9660_dir->filename.str[1]);
reveils that the second string has trailing Rock Ridge garbage:

  ++ WARN: TS_DEBUG: 'LARGE_FILE.;1'
  ++ WARN: TS_DEBUG: 'LARGE_FILE.;1PX$^A<A4><81>'

Both names in their extent records look the same: Length 13, followed by
the thirteen bytes "LARGE_FILE.;1".
So p_iso9660_dir->filename.str is not necessarily terminated by 0 when
this test is made.

With ISO image multi_extent_8k.iso i see no such difference.
Must be salvaged by some lucky 0 in neighboring memory.

We know the valid length and hopefully i know how to properly compare
a 0-terminated string with a length terminated one.


Have a nice day :)

Thomas




reply via email to

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