Messages in this thread | | | Subject | Re: [PATCH 1/1] udf: Fix incorrect final NOT_ALLOCATED (hole) extent length | From | Steve Magnani <> | Date | Wed, 19 Jun 2019 06:47:10 -0500 |
| |
On 6/19/19 1:47 AM, Jan Kara wrote: > Hi Steve! > > On Sun 16-06-19 11:28:46, Steve Magnani wrote: >> On 6/4/19 7:31 AM, Steve Magnani wrote: >> >>> In some cases, using the 'truncate' command to extend a UDF file results >>> in a mismatch between the length of the file's extents (specifically, due >>> to incorrect length of the final NOT_ALLOCATED extent) and the information >>> (file) length. The discrepancy can prevent other operating systems >>> (i.e., Windows 10) from opening the file. >>> >>> Two particular errors have been observed when extending a file: >>> >>> 1. The final extent is larger than it should be, having been rounded up >>> to a multiple of the block size. >>> >>> B. The final extent is shorter than it should be, due to not having >>> been updated when the file's information length was increased. >> Wondering if you've seen this, or if something got lost in a spam folder. > Sorry for not getting to you earlier. I've seen the patches and they look > reasonable to me. I just wanted to have a one more closer look but last > weeks were rather busy so I didn't get to it. I'll look into it this week. > Thanks a lot for debugging the problem and sending the fixes! > > Honza
No worries. If you're short on time I'd suggest looking first at the ways udf_do_extend_file() can be called via inode_getblk(). Those were harder for me to follow so if there is a bug it's most likely in one of those paths.
Regards, ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
| |