Hello list,

We recently had to switch the machine which produces UDF images for our 
products from Ubuntu-12 LTS to Ubuntu-14 LTS.
Unfortunately suddenly all UDF images produced by the new machine were rejected 
by our DVD-ROM manufacturer. Their 
pre production verification step spit out the following message:

    PI51_U14 - Fehler: 
    [e]          DVD       1             Volume Descriptor Sequences are not 
equivalent 
    [w]         DVD       1             Inconsistency between UDF Main and 
Reserve Volume Descriptor Sequence 

I started to investigate and found out that the Volume Set ID is slightly 
different between the original and the copy of the primary volume descriptor.
As these problems remained consistently with images written on the new machine 
we suspected a connection to mkisofs which we use to create our images.
On the old machine we used 3.01a24 whereas on the new machine 3.01a28 is used - 
in both cases directly from the Ubuntu software archives.

I got the sources for both versions and could verify the problem with both 
versions. Then I got 3.02a2 and there I could also verify the problem.
The test script I used is as follows:
    #!/usr/bin/env bash
    here=$(dirname $(readlink -f $0))
    myself=$(basename $0 .sh)
    UDF=${myself}.udf
    LOG=${myself}.log

    MKISOFS=$here/mkisofs/OBJ/x86_64-linux-cc/mkisofs

    $MKISOFS -v -o $UDF -log-file $LOG -udf -follow-links -joliet 
-rational-rock -pad -volid DVD1 -appid PI51 -publisher "Rudolf Haufe Verlag 
GmbH & Co KG" -input-charset iso8859-1 -iso-level 3 $here/mkisofs
    main_vds=/tmp/$$.main
    reserve_vds=/tmp/$$.reserve
    trap "rm -f $main_vds $reserve_vds" 0 1 2 3 5 15
    dd if=$UDF bs=2048 skip=32 count=16 of=$main_vds 2>/dev/null
    dd if=$UDF bs=2048 skip=48 count=16 of=$reserve_vds 2>/dev/null
    cmp -l $main_vds $reserve_vds | egrep -v '^ 
*(5|13|2053|2061|4101|4109|6149|6157|8197|8205|10245|10253) +'

Don't get confused by the egrep call on the last line - it sorts out the 
locations in the descriptor tags which differ by default.
On unmodified sources this script produces the following output:
    3.02a02 (x86_64-unknown-linux-gnu)
    re-directing all messages to HAUFECHECK.log
        9  10 227
       10 151 354
       87  70  71
       88 102  61
       89  66  62

Further investigation showed that the difference is in the Volume Set 
Identifier field at Offset 72 in the Primary Volume Descriptor.

I then went through mkisofs' sources and could locate the problematic code at 
line 1990 in mkisofs/udf.c in routine udf_main_seq_write.
That routine is called twice - once to write the main VDS and then again to 
write the reserve VDS.
Between calls to that routine some time passes so that the call to clock() 
returns a slightly different time when called the second time.
To fix that problem I used the tv_usec field of "tv_begun" which is initialized 
directly after "begun" and then left stable.

The complete patch looks like this:

diff --git a/mkisofs/udf.c b/mkisofs/udf.c
index 25feca6..04390e2 100644
--- a/mkisofs/udf.c
+++ b/mkisofs/udf.c
@@ -98,7 +98,7 @@ static        UConst char sccsid[] =
 extern int     use_sparcboot;

 extern struct directory *root;
-extern struct timeval  tv_begun;
+extern time_t          begun;

 static unsigned lba_main_seq;
 static unsigned lba_main_seq_copy;
@@ -723,7 +723,7 @@ set_primary_vol_desc(buf, lba)
        /*pvd->volume_abstract;*/
        /*pvd->volume_copyright_notice;*/
        /*pvd->application_ident;*/
-       set_timestamp_from_time_t(&pvd->recording_date_and_time, 
tv_begun.tv_sec);
+       set_timestamp_from_time_t(&pvd->recording_date_and_time, begun);
        set_impl_ident(&pvd->impl_ident);
        set_tag(&pvd->desc_tag, UDF_TAGID_PRIMARY_VOLUME_DESC, lba, 512);
 }
@@ -831,7 +831,7 @@ set_logical_vol_integrity_desc(buf, lba)
        udf_logical_volume_integrity_desc *lvid =
                                (udf_logical_volume_integrity_desc *)buf;

-       set_timestamp_from_time_t(&lvid->recording_date, tv_begun.tv_sec);
+       set_timestamp_from_time_t(&lvid->recording_date, begun);
        set32(&lvid->integrity_type, UDF_INTEGRITY_TYPE_CLOSE);
        /*lvid->next_integrity_extent;*/
        set64(&lvid->logical_volume_contents_use.unique_id,
@@ -859,7 +859,7 @@ set_file_set_desc(buf, rba)
 {
        udf_file_set_desc *fsd = (udf_file_set_desc *)buf;

-       set_timestamp_from_time_t(&fsd->recording_date_and_time, 
tv_begun.tv_sec);
+       set_timestamp_from_time_t(&fsd->recording_date_and_time, begun);
        set16(&fsd->interchange_level, 3);
        set16(&fsd->maximum_interchange_level, 3);
        set32(&fsd->character_set_list, 1);
@@ -1986,8 +1986,8 @@ udf_main_seq_write(out)
         * volume_set_id needs to be set to a (64-bit) "unique" number.
         * This will have to do for now.
         */
-       volume_set_id[0] = tv_begun.tv_sec;
-       volume_set_id[1] = (unsigned)tv_begun.tv_usec;  /* XXX Maybe 
non-portable */
+       volume_set_id[0] = begun;
+       volume_set_id[1] = (unsigned)clock();   /* XXX Maybe non-portable */

        memset(buf, 0, sizeof (buf));
        set_primary_vol_desc(buf, last_extent_written++);

That fixed the problem for us.

Cheers,

Gottfried Ganßauge 
Entwickler
Content Engineering & Development

------------------------------------------------------------------
Haufe-Lexware GmbH & Co. KG
Ein Unternehmen der Haufe Gruppe
Munzinger Str. 9, 79111 Freiburg
Tel. +49 761 898-0
E-Mail: gottfried.ganssa...@haufe-lexware.com
Internet: http://www.haufe-lexware.com
------------------------------------------------------------------
Kommanditgesellschaft, Sitz und Registergericht Freiburg, HRA 4408
Komplementäre: Haufe-Lexware Verwaltungs GmbH,
Sitz und Registergericht Freiburg, HRB 5557; Martin Laqua
Beiratsvorsitzende: Andrea Haufe
Geschäftsführung: Isabel Blank, Markus Dränert, Jörg Frey, 
Birte Hackenjos, Randolf Jessl, Markus Reithwiesner,
Joachim Rotzinger, Dr. Carsten Thies
------------------------------------------------------------------


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
Cdrtools-developers mailing list
Cdrtools-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdrtools-developers

Reply via email to