[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, hea
From: |
Rocky Bernstein |
Subject: |
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming |
Date: |
Mon, 5 Mar 2012 23:13:34 -0500 |
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
>
>
- [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/04
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/04
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/04
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/05
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/05
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/05
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming,
Rocky Bernstein <=
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/06
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/06
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/08
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/09
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/10
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/11
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/11
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/12
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/14
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/14
- Prev by Date:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Next by Date:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Previous by thread:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Next by thread:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Index(es):