[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libcdio-devel] [PATCH 0/5] Integration of libcdio-pbatard changes

From: Pete Batard
Subject: [Libcdio-devel] [PATCH 0/5] Integration of libcdio-pbatard changes
Date: Fri, 10 Feb 2012 19:34:32 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0

With libcdio-pbatard now complete in terms of fixes and features, I am in a position to push for the changes to be integrated into mainline at last.

As previously indicated I have created a new pbatard-integration branch dedicated where I will push a few commits at a time, with a copy of those also being sent to the mailing list, and will wait for integration before pushing some more.

While I was at it, you will see that I added a MSVC project for cd-paranoia in -pbatard, mostly because I was observing a crash there during testing, that was a lot easier to troubleshoot using MSVC. I have also applied fixes for tests that I found problematic, so that they now all work properly, including with MinGW (the only one that fails on MinGW now is rock-ridge, which is purely due to symbolic links not being available for extracted data on Window).

The way I'd like to proceed, which is also how I am planning to submit patches, is to have the fixes and extract.c sample integrated first, since not having them will hinder testing, then get the cumbersome but minor stuff out of the way (source headers improvements), then ensure that we have a set of tests that work on all platforms (there are a few things to address there) before finally going to the main course with core file patches.

The 5 patches from this first salvo should be fairly independent and will stop short of the testing fixes.



PS: On a side note I'm quite pleased to have stuck with libcdio in my app and not switch to using 7-zip or something else, as tests shown that my application is about twice as fast on UDF extraction as the competition [1]. Of course, this is in great part due to the default Windows buffering mechanisms, since I haven't optimized anything with regards to extraction, and everything is very much read one block at time, but it also indicates that the libcdio code is not slowing us down in any way. Good job!

[1] -> "(1) Speed comparison between Rufus and other applications"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]