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

[Pete Batard]

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

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.

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.

Note that I tested quite a few bootable ISO9660 images with Joliet, 
since I'm dealing with these a lot in my app. 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.

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.

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.

Regards,

/Pete