On Mon, Mar 5, 2012 at 8:25 PM, Pete Batard <[email protected]> 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 > >
