Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming

[Rocky Bernstein]

On Mon, Mar 5, 2012 at 8:25 PM, Pete Batard <address@hidden> wrote:

> OK, pbatard-integration2 should now be pretty much in line with -pbatard,
> short of additional patches that will be required for MSVC project files
> (but those are fairly independent).
>

I have tested these on the various platforms and everything works!

All your changes are now merged into master.




> Unfortunately, the paranoia removal commits are a bit all over the place,
> as I had connectivity issues today, and didn't see your last message till
> late. The 3 paranoia related changes as well as the .cvsignore removal can
> probably be grouped into one commit without too much trouble.
> There's also a libcdio_cdda.pc.in in root that seems to be paranoia
> related, that I haven't touched and that may be removable.
>

I've just removed it.

>
> Outside of paranoia, the commits should be fairly explicit, starting with
> the _cdio_strdup_fixpath one, that should keep Windows native calls happy
> even with non native paths. For anything non Windows, this call just does a
> strdup, so I don't expect much of an issue.
>
> Following this commit are the Joliet related improvements and fixes. A fix
> was needed first of all because an ISO9660 disc may have more than one
> secondary volume descriptor (eg. El-Torito + Joliet), and the existing code
> only looked for Joliet in the first SVD.
> While I was fixing Joliet, I addressed the TODO regarding fallback to
> non-Joliet, in case Joliet and non-Joliet match and non-Joliet may be
> longer. I also factorized much of the iso9660_get_####_id() calls.
>

Thanks!

>
> Note that I tested quite a few bootable ISO9660 images with Joliet, since
> I'm dealing with these a lot in my app.


I regret that the problems and fixes that you encounter are currently
mostly known and reproducible by you. That generally means that sometime in
the future someone somewhere (read: me) will break things. Sure, I
understand it is *work* to isolate problems into small reproducible test
cases, but I also subscribe to the view that  programming, development and
testing can be incremental.

So if there are images that libcdio had problems, a simple, low-tech thing
to do is jot down in a file somewhere the image and its characteristics and
what is expected. Even if this is a text file rather than code, it means
someone has a hope in the future to try to go further.

To further suggest the usefulness of this approach, consider that TODO item
you reported on above. It is possible that if I hadn't written that, you
might not have considered implementing it.



> The only image I found to fail to have an issue was haiku-r1alpha3.iso,
> but, at least according to disktype-9 it's because it uses Joliet but
> doesn't have a Joliet SVD, so it's pretty much invalid ISO9660.
>
> Next are Windows related fixes to enable stat()/fopen() of UTF-8 paths.
> Unlike UNIX, Microsoft took the very insane decision of not making existing
> char* calls UTF-8 compatibles, but instead force all Windows developers to
> go through cumbersome wchar_t strings whenever Unicode is required, which
> of course prevents the opening of streams that contain extended characters.
> This commit addresses that and was also validated, at least for the opening
> of ISO images, in my app.
>

Again, I'd suggest jotting down in a file somewhere we can distribute with
libcdio such an example image that one might be able to easily obtain.

>
> Then comes a commit where I grouped various smaller issues, including one
> related to LFS. The commit message provides a bit more details about each
> one.
>
> Next comes an old favourite of mine with some more source header
> harmonization, primarily aimed at the test sources. These aren't that
> important, but we might as well try to be consistent with the code.
>
> Next is yet another Windows specific workaround for the lack of a glob()
> call.
>
> Then, at last, comes the UDF fix for MSVC compilers. A bit intrusive for
> non MSVC platforms, since we have to place a non empty member into an
> union, but if we go with the alternative of trying to add #ifdef _MSC_VER
> fixups every time we use a sizeof of one of the problematic UDF structs,
> we're pretty much assured that someone will modify the code and forget that
> sizeof needs a fixup, and we will run into problems that aren't so easy to
> troubleshoot.
>

There has been interest in the past to support Sun's C compiler and that
has the same problem as well. So not using #ifdef _MSC_VER is appreciated.



>
> With these applied, master should be pretty much in sync with -pbatard,
> with a MinGW compilation that should behave as expected (though I haven't
> tested anything that has to do with recording, and only ran limited test
> with physical device access).
>
> The one item I still have open for MinGW is the rockridge test: If you
> configure libcdio with --enable-rock, the rockridge test fails with the
> following:
>
> --- copying-rr.dump     2012-03-06 00:51:10 +0000
> +++ ./copying-rr.right  2012-01-23 11:01:04 +0000
> @@ -4,19 +4,19 @@
>   dr-xr-xr-x   4 0 0 [LSN     23]      2048 Oct 22 2004 02:21:14  .
>   dr-xr-xr-x   2 0 0 [LSN     23]      2048 Oct 22 2004 02:21:14  ..
>   dr-xr-xr-x   2 0 0 [LSN     24]      2048 Mar 05 2005 16:12:25  copy
> -  -r-xr-xr-x   1 0 0 [LSN     27]         0 Mar 05 2005 15:26:00  Copy2
> +  lr-xr-xr-x   1 0 0 [LSN     27]         7 Mar 05 2005 15:26:00  Copy2
> -> COPYING
>   -r--r--r--   1 0 0 [LSN     27]     17992 Mar 05 2005 15:25:51  COPYING
> -  -r--r--r--   1 0 0 [LSN     36]         0 Mar 05 2005 15:32:05  fd0
> +  br--r--r--   1 0 0 [LSN     36]         0 Mar 05 2005 15:32:05  fd0
>   dr-xr-xr-x   2 0 0 [LSN     25]      2048 Mar 05 2005 16:12:25  tmp
>   cr--r--r--   1 0 0 [LSN     36]         0 Mar 05 2005 15:31:42  zero
>
>  /copy/:
>   dr-xr-xr-x   2 0 0 [LSN     24]      2048 Mar 05 2005 16:12:25  .
>   dr-xr-xr-x   4 0 0 [LSN     23]      2048 Mar 05 2005 16:12:25  ..
> -  -r-xr-xr-x   1 0 0 [LSN     36]         0 Mar 05 2005 15:27:05  COPYING
> +  lr-xr-xr-x   1 0 0 [LSN     36]        10 Mar 05 2005 15:27:05 COPYING
> -> ../COPYING
>
>  /tmp/:
>   dr-xr-xr-x   2 0 0 [LSN     25]      2048 Mar 05 2005 16:12:25  .
>   dr-xr-xr-x   4 0 0 [LSN     23]      2048 Mar 05 2005 16:12:25  ..
> -  -r-xr-xr-x   1 0 0 [LSN     36]         0 Mar 05 2005 15:51:05  COPYING
> +  lr-xr-xr-x   1 0 0 [LSN     36]        18 Mar 05 2005 15:51:05 COPYING
> -> ../copying/COPYING
>
> ./check_iso.sh: iso-info Rock Ridge test failed.
> ./check_iso.sh: failed command:
>        ../src/iso-info.exe  --quiet ./data/copying-rr.iso --iso9660
> FAIL: check_iso.sh
>
> As highlighted, the problem has to do with the symbolic links, which
> Windows cannot recreate on extraction. Not sure how we want to address this.
>

A simple thing to do is to skip this test on MinGW with Joliet enabled.


> Regards,
>
> /Pete
>
>