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 :|