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: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/cdrtools-developers
