On Tue, Jan 17, 2012 at 7:25 AM, Pete Batard <[email protected]> wrote:
> On 2012.01.17 02:35, Rocky Bernstein wrote: > >> Thanks for the investigation, information and patches. UDF support hasn't >> had much love for a long while, if ever. >> >> UDF support is something that a number of people have asked for, but no >> one >> was willing to step up to the plate to work on. For myself, it's just not >> something I feel like I want to work on even though, yes, I started that >> code. >> > > Well, while I understand where you're coming from, if UDF support is > unreliable, that suddenly makes libcdio a lot less interesting for my > project. I had considered using the ISO/UDF code from 7-zip (which is > public domain AFAIK) but decided against it mostly because it is C++, > completely undocumented, And although I haven't looked in a while, I think the UDF code in kernel drivers in various OS's like GNU/Linux is also undocumented. > and also because I prefer reusing (and contributing to) GPL 3.0 projects > whenever possible. > Great! > > Sill, all recent Windows installation media are UDF so I need UDF support > that can at least extract files from. If that becomes too troublesome, I may have to reconsider. > > > I'm okay with applying these patches as is on the theory that it moves >> code >> forward which is better than keeping it slightly broken. >> > > Since this is a fairly blind workaround, which might cause more harm than > good (it may break file access --only directory content listing was tested > so far), I'd rather not have it applied. Oh, I forgot to ask -- are we sure this is a bug in libcdio? It is possible that it was valid at the time it was written for an earlier UDF standard. A while back there was a UDF checker I think it was available from Sony that dumped out UDF information and said whether something was valid UDF. I'd be interested in knowing if what you are testing passes a UDF checker. (A google search on UDF checkers seems to indicate there are a number available for MS Windows). Once I'm done experimenting with UDF file extraction, I'll see if I can > provide something better... > > > We have crappy code which is >> only good enough to lure someone into deciding to investigate some aspect >> that they need or are interested in; and then they rewrite it. >> > > Well, I didn't want to comment, but yeah, some aspects of libcdio looked a > bit disputable to me (especially that reuse of udf_dirent_t). > > As long as I use libcdio, I'll try to feed patches back to improve it --at > least for the areas that I'm familiar enough. > Thanks. > > Regards, > > /Pete > > PS: Thanks for applying the previous patches > >
