On Tue, Jul 13, 2010 at 03:00:33AM -0400, Laine Stump wrote:
> We were previously checking for a return < 0 from virFileOperation(),
> but that function returns a standard errno, which is 0 on success, or
> some small positive number on failure. The result was that we wouldn't
> report failures to create storage volume files; instead they would
> appear to be created, but then would vanish as soon as a pool-refresh
> was done (or cause some later error as soon as someone tried to access
> the volume).
Urgh, functions that return positive numbers for errors are just
asking for trouble. If you see an 'int' returning function everyone
expects it to return < 0 on error, even if you document otherwise.
> The other uses of virFileOperation() were already properly checking
> for != 0.
> ---
> src/storage/storage_backend.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
> index aba8937..9792eed 100644
> --- a/src/storage/storage_backend.c
> +++ b/src/storage/storage_backend.c
> @@ -362,7 +362,7 @@ virStorageBackendCreateRaw(virConnectPtr conn ATTRIBUTE_UNUSED,
> createRawFileOpHook, &hdata,
> VIR_FILE_OP_FORCE_PERMS |
> (pool->def->type == VIR_STORAGE_POOL_NETFS
> - ? VIR_FILE_OP_AS_UID : 0))) < 0) {
> + ? VIR_FILE_OP_AS_UID : 0))) != 0) {
> virReportSystemError(createstat,
> _("cannot create path '%s'"),
> vol->target.path);
I'd rather we changed virFileOperation to return '-errno' so all error
return codes are negative, and then fixup other callers
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list