fwrite() returns the number of items written. But when there is one
error, it can return a short write.
In the particular bug that I was tracking, I did a migration to a
read-only filesystem. And it was able to finish the migration
correctly. fwrite() never returned a negative error code, the 1st
time it returns 0, after that it returns 4096. (migration writes
chunks of about 14000 bytes). And it was able to "complete" the
migration with success (yes, reading the file was a bit more
difficult). On the 1st fwrite() for the read-only filesystem,
it returns an errno of -EPIPE, that is exactly what has failed.
To add insult to injury, if your amount of memory was big enough (12GB
on my case), it overwrote some important structure, and from them,
malloc failed. This check makes the problem go away.
Signed-off-by: Juan Quintela <quint...@redhat.com>
---
v2: a.k.a Paolo was right
On the first call to fwrite() it returns 0, and errno is setup to
EPIPE, exactly what we wanted.
Once here, improve the commit message.
qemu-file.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/qemu-file.c b/qemu-file.c
index 9473b67..e5ec798 100644
--- a/qemu-file.c
+++ b/qemu-file.c
@@ -100,7 +100,14 @@ static int stdio_put_buffer(void *opaque, const uint8_t
*buf, int64_t pos,
int size)
{
QEMUFileStdio *s = opaque;
- return fwrite(buf, 1, size, s->stdio_file);
+ int res;
+
+ res = fwrite(buf, 1, size, s->stdio_file);
+
+ if (res != size) {
+ return -errno;
+ }
+ return res;
}
static int stdio_get_buffer(void *opaque, uint8_t *buf, int64_t pos, int size)
--
1.8.5.3
