[DVDnav-discuss] Libdvdread misses hidden files and causes segfaults to calling programs [patch attached]

[John Stebbins]

On 09/19/2011 04:18 PM, Alexander Roalter wrote:
> Ok, then here goes a minimal invasive patch:
> 
> I still like my first try better, but I understand noone has any desire to review it.
> 
> On a side note: The linux UDF driver does show the file correctly. Since libdvdread brings its own UDF implementation,
> it doesn't need to mount the DVD in order to access it. This much I understand. Now a question: would it be possible to
> use such an approach also for blu-ray? Currently, I have to mount the drive in order to access it with the br://
> interface, but if my thoughts are correct, the same method could be applied to it, so one wouldn't have to mount the
> drive beforehand. On the other hand, I reckon there are much more different file accesses to be done, which are much
> more easier to go through the normal api instead of the own UDF driver.
> Again, if libdvdread would have used the linux driver (and would require to mount the device), then this error wouldn't
> have happened (and I would call it an error, since it's a legal (?) file name that gets truncated and therefore fools
> the current implementation.
> 

This last patch looks good to me.  But note that I have not yet had a chance to test this fix.  Still waiting on
delivery of my Thor disc.

Regarding UDF for bd access.  The version of UDF used for DVD is older than the one used for BD.  So at the least, the
code needs to be updated.  However, personally I do not like the tightly bound implementation dvdread uses.  I would
prefer a separate libudf that an application can link in (or not link in as it chooses).  The relevant functions (read,
write, readdir, etc...) in libbluray would have to be substitutable by some registration mechanism.  And this has been
done already (see bd_register_file and bd_register_dir).  So it would be up to the application to add the udf library
and create the linkage to it through the file and directory methods.

-- 
John      GnuPG fingerprint: CADFA1DB594CA50EB79427284617578AADE759A1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/attachments/20110919/88d3970e/attachment.asc>