This would solve the issue I noted months ago:

http://sourceforge.net/p/cdrtools/mailman/message/34410200/

--
Jonatã Bolzan Loss

On Wed, Nov 25, 2015 at 4:40 PM, Ganssauge, Gottfried <
gottfried.ganssa...@haufe-lexware.com> wrote:

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