On Sat, Oct 23, 2010 at 5:02 AM, Thomas Schmitt <[email protected]> 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 > > >
