file reports negative size for QCOW images

This seems to have gotten worse. The output is now:

 test.qcow: Qemu Image, Format: Qcow , Version: 1 , Disk Size could be: 0 * 256 bytes

The number reported for disk size does not vary with the actual size of the image. qcow2-format images don't have any estimated size reported at all.

This is file 4.23-2 downloaded from the Intrepid repository and running on Gutsy. (I manually specified the just-built magic file.)

Packages:
$ dpkg -l | grep qemu
ii kqemu-common 1.3.0~pre11-8 Common files for the QEMU Accelerator module
ii kqemu-modules-2.6.22-14-generic 1.3.0~pre11-6+2.6.22-14.52 kqemu modules for Linux (kernel 2.6.22-14-gene
ii kqemu-modules-2.6.24-16-generic 1.3.0~pre11-8+2.6.24-16.30 kqemu modules for Linux (kernel 2.6.24-16-gene
ii kqemu-source 1.3.0~pre11-8 Source for the QEMU Accelerator module
ii qemu 0.9.1-1ubuntu1 fast processor emulator
$ uname -r
2.6.24-17-generic
$
Currently running Ubuntu 8.04 with all current updates, backports and security updates, except kernel.

Debug:
$ qemu-img create -f qcow test.qcow 2G
Formatting 'test.qcow', fmt=qcow, size=2097152 kB
$ file test.qcow
test.qcow: QEMU Copy-On-Write disk image version 1, size 0 + -2147483648
$ qemu-img create -f qcow2 test.qcow 2G
Formatting 'test.qcow', fmt=qcow2, size=2097152 kB
$ file test.qcow
test.qcow: QEMU Copy-On-Write disk image version 2, size 0 + -2147483648
$

Attached find essentially the same debdiff I sent to Debian; it just has the version number in it changed, and the changelog entry refers to the Launchpad bug number rather than the Debian one. Apart from that, it's the same patch.

As I said on the Debian bugtracker, I ran into two non-critical issues. First, the backing-file name isn't stored in a NUL-terminated format; pretending that it's NUL-terminated seems to work, but since I couldn't figure out how to specify a string length based on an indirect value, it's not being done the *right* way. Second, The offset to the backing-file name in qcow2 images is a 64-bit quantity, but there's no way to put in a 64-bit offset. I cheated and assumed that the top four bytes are zero; this works on newly-created images, at least, though I can't guarantee that it'll work in the general case.