On 02.10.2015 15:41, John Ferlan wrote:
As it turns out the caller in this case expects a return < 0 for
failure
and to get/use "errno" rather than using the negative of returned status.
Again different than the create path.
If someone "deleted" a file from the pool without using virsh vol-delete,
then the unlink/rmdir would return an error (-1) and set errno to ENOENT.
The caller checks errno for ENOENT when determining whether to throw an
error message indicating the failure. Without the change, the error
message is:
error: Failed to delete vol $vol
error: cannot unlink file '/$pathto/$vol': Success
This patch thus allows the fork path to follow the non-fork path
where unlink/rmdir return -1 and errno.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
src/util/virfile.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/util/virfile.c b/src/util/virfile.c
index 3d7efdc..a81f04c 100644
--- a/src/util/virfile.c
+++ b/src/util/virfile.c
@@ -2364,8 +2364,10 @@ virFileRemove(const char *path,
status = EACCES;
}
- if (status)
- ret = -status;
+ if (status) {
+ errno = status;
+ ret = -1;
+ }
return ret;
}
Yep, this matches not only the rest of the function (e.g. when unlinking
without forking) but the win32 impl too. Checked all the callers (ehm,
so far the only one), and this behaviour is expected there too.
ACK
Michal