StorageVolUpload corrupts image about go-libvirt HOT 5 CLOSED

The actual size of that image file (https://cloud-images.ubuntu.com/minimal/releases/disco/release-20190605/ubuntu-19.04-minimal-cloudimg-amd64.img) is 155MB, so for your test that uses a large buffered reader, the image will fit completely in the reader's buffer. I suspect that's a clue. Can you try this test without using the progress bar's ProxyReader? I'm wondering if that code has a bug that causes it to report that the transfer is complete, when it actually isn't.

from go-libvirt.

@trapgate thank you for your answer. That was also my first guess, but the ProxyReader does not cause the problem. The same problem appears without progress bar.
To check if StorageVolUpload consumes all data from the reader I used the CountReader in my example. The number of bytes read from the http stream and from the file are the same. However, in the end the image from http has a smaller size in /var/lib/libvirt/images.

-rw------- 1 root root 162529280 20. Jun 21:38 /var/lib/libvirt/images/image_from_file
-rw------- 1 root root 162512896 20. Jun 21:39 /var/lib/libvirt/images/image_from_http

To me it looks that something is not properly flushed in the end.

from go-libvirt.

@dsbrng25b do you run Flush method and check error from it and from Close method?

from go-libvirt.

@vtolstov I used defer resp.Body.Close() for the http stream. Now I moved the resp.Body.Close() before the ConnectClose and checked for errors but it does not return an error.
Which Flush method do you mean? As far as I understand a Flush or Close method is not required because the StorageVolUpload accepts an io.Reader. So to my understanding StorageVolUpload should Read until io.EOF.

from go-libvirt.

I found the problem. The sendStream function does not return remaining bytes on io.EOF (see #83).

from go-libvirt.