[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rocky Bernstein
Subject: Re: [Libcdio-devel] Re: can files in UDF be fragmented?
Date: Sat, 23 Oct 2010 10:55:42 -0400

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]