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