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

[Rocky Bernstein]

On Sat, Oct 23, 2010 at 5:02 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> > So right now it's up to the caller to make sure an extent isn't exceeded.
>
> Quite a plight.
>
> I riddle how to get more than one pair of LBA and size from a file.
> From udf_dirent_t i can call udf_get_file_entry() for udf_file_entry_t
> and then udf_get_lba().
>
> But the only way to see the multi-extent aspect of udf_file_entry_t
> seems to be via <libcdio/ecma167.h> struct udf_file_entry_s.alloc_descs .
> That's a byte array. Specs are in ECMA-167 4/14.14.
>
> Quite helpful is  udf_file_entry_[ts].i_alloc_descs  which i
> recognize from ECMA-167 as the extent counter.
> So all is well if this is 1.
>
> Would it make sense to introduce an API call like
>  bool udf_is_multi_extent(const udf_file_entry_t *p_udf_fe)
> or even more informative
>  int udf_get_file_extents(const udf_file_entry_t *p_udf_fe, int array_size,
>                           uint32_t starts[], uint32_t ends[])
> (Would return number of extents. To be called first with array_size==0
>  and again with a starts[] and ends[] of a size sufficient for the
>  returned number of extents.)
>
>
> > 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.
>
> It should be done inside udf_read_block().
>

Yes, but see my last post on this.

>
> Further i suspect that the warning in udf_read_block() is never
> triggered. To my understanding it works only if the caller demands a
> read size that is larger than the whole extent. I.e. in the range of GB.
>
> Do you have a test image by which you could try whether subtracting
> the remaining i_offset from p_icb->len yields a still usable *pi_max_size ?
> (Two occurences in offset_to_lba().)
>

No I don't have a test image.


>
> Have a nice day :)
>
> Thomas
>
>
>