On 14.01.20 14:58, Alberto Garcia wrote:
> On Tue 14 Jan 2020 02:47:53 PM CET, Max Reitz wrote:
> 
>>> Yes, but does it make sense to try to support images with unaligned
>>> sizes if no one is going to create them ever and QEMU cannot even
>>> generate them?
>>
>> If nobody uses such images ever, isn’t the current code fine as-is?
> 
> I'll rephrase:
> 
> 1. It is possible to have a qcow2 image with a size of 1 GB + 13 bytes
>    (the size field in the qcow2 header allows it).
> 
> 2. qemu-img cannot currently produce such images.
> 
> 3. QEMU can open them but it gets the size wrong.

Yes, but in a safe way.  The user simply doesn’t get access to those 13
bytes.

With your proposed change, it would just reject the image altogether.
As a user, I’d prefer not being able to access 13 bytes to not being
able to access 1 GB + 13 bytes.

Furthermore, the user couldn’t even fix the image then because they
couldn’t resize it with qemu-img resize.

> 4. Fixing this in QEMU involves non-trivial changes (at least at the
>    moment).
> 
> 5. I don't think there's any use case for such images so instead of
>    fixing QEMU I propose that we simply refuse to open them.

If there’s no use case, I don’t see how the current behavior is problematic.

The arguments I could immediately agree to are (1) simplicity, and (2)
the image is probably corrupted.

As for (1), this patch adds more lines than it removes, so from a pure
quantitative standpoint, it doesn’t make the code simpler.

As for (2), I’m always of the opinion we shouldn’t refuse to read
corrupted images just because they are corrupted.  We should open them
and let the user read as much as is reasonably possible.

Max