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@xxxxxxxxxx>
> ---
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list