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 also because I prefer reusing (and
contributing to) GPL 3.0 projects whenever possible.
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. 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.
Regards,
/Pete
PS: Thanks for applying the previous patches
