work - so we'll short circuit here.
This also rejects the non-stable path '/dev' that was accepted before.
Not quite sure I see the issue - can you be more specific? Am I missing something obvious?
Previously if "pool->def->target.path" is "/dev" (or NULL or "/dev/" or didn't start with "/dev"), then we'd return a strdup'd 'devpath' into 'vol->target.path'.
I see no way 'devpath' could be '/dev' or '/dev/' since it is formatted as :
if (virAsprintf(&devpath, "/dev/%s", dev) < 0) goto cleanup;
That's the path to the device. The comment above is right about checking the pool target path in the pool definition.
After this patch, if pool->def->target.path is "/dev", we wouldn't even get to the virStorageBackendStablePath call, because of the check in virStorageBackendPoolUseDevPath - it will return false, we'll jump to cleanup and skip over this volume.
Hmmm.. maybe I need to think outloud... Assume I change the check to: if (!virStorageBackendPoolPathIsStable(pool->def->target.path) && !(STREQ(pool->def->target.path, "/dev") || STREQ(pool->def->target.path, "/dev/"))) { So, if pool->def->target.path is "/dev", then we'll alloc vol, formulate 'devpath', then call virStorageBackendStablePath. Then virStorageBackendPoolPathIsStable is called which returns false because the pool->def->target.path is "/dev". That causes us to strdup the incoming "/devpath" and return. Upon return we'd end up returning -2 to the caller. So, is this the path you were considering? If not, then please describe in detail. As it turns out setting pool->def->target.path to "/dev" or "/dev/" doesn't cause us to follow down the path of the virReadDir (could take a while if it did). Help turn the lightbulb on! John