On Sat, Oct 23, 2010 at 7:03 AM, Thomas Schmitt <[email protected]> wrote:
> Hi, > > i have to correct myself. In previous mail i wrote: > > > 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. > > The size is counted in bytes and not in descriptor records. > So it is safe if udf_file_entry_t.i_alloc_descs is 8 or 20. > It might be safe with 16, but then one needs to make sure it is > a single "long_ad" and not two "short_ad". > > For the interpretation one would have to check: > > udf_file_entry_t.icb_tag.flags & ICBTAG_FLAG_AD_MASK > > for ICBTAG_FLAG_AD_SHORT, ICBTAG_FLAG_AD_LONG, ... > > (I did not check whether all these symbols are public. They are public. > That approach is > educating for me, but unappealing for any user of the library.) > Yep. Based on what you report, it looks like udf_read_block has all the information it needs to check. From udf_dirent_t, it could get udf_file_entry_t.i_alloc_descs However, since I don't have test UDFs to work against, I am not inclined to pursue this further. > > ------------------------------------------------------------------------ > > > For the original topic of this thread: > > The extent size of "short_ad" is restricted to 1 GB - 1. > So a reason for fragmentation might already be given if a file is 1 GB > or larger. > That's a necessary reason but not the only reason. Another reason one finds files with noncontiguous regions occurs after the file is modified. > > > Have a nice day :) > > Thomas > > >
