Re: [Libcdio-devel] Re: can files in UDF be fragmented?

[Rocky Bernstein]

In git commit 621e41e..05a2fb6, I have made that warning more severe by
using stderr instead of stdout as suggested. I've also updated the doxygen
function comment and added what action is taken when this happens.

So right now it's up to the caller to make sure an extent isn't exceeded. At
such later time when we run across this, I think it will be apparent what to
do and perhaps we'll have a better handle on whether the responsibility is
on this function to take action (and therefore how to address) or is the
caller's responsibility as is and has been the case so far.

Also,  as discussed before, udf_read_block is exposed and udf_dirent_t is no
longer opaque.

On Fri, Oct 22, 2010 at 6:20 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> > Thomas - you do have commit rights to libcdio, so if you want to fix the
> > faulty code, by all means do so. Or if you want to make a patch and send
> > that to me and/or have me double check, I'd be happy to do that.
>
> I would try ... if i had a test case.
>
> Obviously the existing code is aware of multi-extent files.
> The bug which i believe to see and the obvious unimplemented handling
> of extent boundaries tell me that nobody ever tested libcdio with
> such UDF images.
> Do such images exist at all in real life ?
> (I'd look at Blu-ray movie discs for files >= 4 GB. On DVD they are
>  unlikely to find.)
>
> I myself am still very clueless about UDF.
> It is all 4 times more complicated than in ECMA-119 plus Rock Ridge.
> Even the simple things are explained awkwardly.
>
> ---------------------------------------------------------------------------
>
> How about you put remarks at both spots in the code and change the
> rather riddling warning message:
>
> -        printf("Warning: don't know how to handle yet\n" );
> +        fprintf(stderr,
> +        "libcdio: Warning: Encountered UDF file with multiple
> extents.\n");
> +        fprintf(stderr, "libcdio: Cannot handle this properly yet.\n");
>
>
> Next would be to test whether subtracting i_offset from *pi_max_size
> is the right thing to do.
> If i am wrong, then this would break well working use cases.
>
> But if i am right then it would at least cause the warning to pop up
> at the appropriate occasions.
> Currently it looks as if the test is too lax and will often allow to
> read over the end of an extend.
>
> Do we have testers for vanilla UDF reading via libcdio ?
>
>
> Have a nice day :)
>
> Thomas
>
>
>