[Top][All Lists]

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

Re: [Libcdio-devel] [PATCH] UDF+ISO image extraction sample (and a plan

From: Pete Batard
Subject: Re: [Libcdio-devel] [PATCH] UDF+ISO image extraction sample (and a plan for upcoming changes)
Date: Mon, 23 Jan 2012 17:04:47 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

On 2012.01.23 15:03, Rocky Bernstein wrote:
Ok. Since I think it important, unless there are other volunteers I'll look
into adding tests for the very specific bugs that are encountered.

I very much appreciate that! And I'll try to help as much as I can.

To give you an idea of what's in store, here are the 4 tests we would need to have an image for then:
- multiple files that can be extracted sequentially (hopefully easy)
- at least one file with extended attributes and allocated descriptors that result in a File Entry that is greater in size than the last one used. I'm not exactly sure how the reuse is supposed to occur, and since it doesn't matter with my proposed fix, I haven't investigated, but this may be linked to the next test below, as the problem manifests itself with files that are larger than 1 GB apparently - at least one file that uses multiple extents (or whatever the UDF specs calls it). In the case of the Windows UDF, a new extent is used for every 1 GB of data. Now, my tests with the Windows UDF show that the current libcdio handles it properly (good job!), but we'd still probably want that in an image. - at least one file that is larger than 4 GB. Most likely 2 GB will do, as I think all the 32 bit issues I spotted were with signed values, but we might as well go for 4 to be safe.

Additionally, having some filenames in CJK for instance, to test/implement Unicode preservation would be welcome (I assume most of us will be testing with a Western locale).

And as I wrote before, having even slightly better UDF support may be just
enough to lure more people to handle all those other more thorny issues.

That's what I'm hoping as well, as I'd rather benefit from other people from fixing issues that I may end up experiencing otherwise ;)

I understand where you are coming from, but suggest even in those other
projects it may be a mistake. With testing there is a chicken-and-egg
bootstrap problem. Unless one is working in an environment like
Ruby-on-Rails where there already has been a lot of work done to support
testing (even to the extent of automatically cloning databases), there is
some initial hit one takes in setting up tests. But after doing that, the
testing becomes easier. And the pay-off in my view is worth the work done.

Agreed. That also has a lot to do on whether you are in for the short or the long term.

Here is something similar. You just wrote an example program. It was
probably easier to do because there were other example programs and the
build framework to cut and paste from.

Absolutely! Most of the extract.c sample is copy/paste of existing libcdio samples, and I'm very grateful for that. However, the main issue here is not sample accessibility but accessibility of data to test the samples against, in order to check for potential problems.

My view, and this is also part of the reason I can't see myself spending much time crafting an UDF test image, is that even after Microsoft removes the Windows 8 preview UDF from public availability, an awful lot of libcdio users should still be able to get their hands on a Windows installation image to display the same (potential) symptoms. All the Windows 7 images I tested with do and I fully expect the release Windows 8 media to do as well.

Of course, if no public Windows image is available from Microsoft or elsewhere, I'm not too happy about the idea of punishing libcdio users that work with Linux, Solaris, BSD, OSX, etc exclusively. But the sheer market penetration of Windows means that most of these users should be able to find someone who can provide one.

Experience has shown that the
example programs have been very helpful, although when I wrote the first
ones, it felt more as an afterthought.

Yeah. The other side of the equation, which I've seen with libusb, can also occur if, after finding that samples are lacking, you decide to write a generic one that tests a handful of features, instead of going with a myriad of samples that perform single but very elementary tests, and the maintainers of the project decide that having no sample at all is better than having one that does too much...

As a matter of fact, the extract sample is designed to work for both ISO9660 and UDF images. While I'm aware that this could be split into an iso-extract.c and an udf-extract.c, I sure hope you're not going to ask for that, because (since it isn't that large) I think it'll be more beneficial for libcdio users this way.

So again, perhaps if a framework for testing UDF images is started adding
to that for bugs that you want to fix won't be too much trouble. And there
may be some code in the testing that you can use on the other projects.

Ack. As I said, my main problem is the time I want to spend. Otherwise, I'm all for having a reliable testing framework as well.



reply via email to

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