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

[Thomas Schmitt]

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().

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().)


Have a nice day :)

Thomas