search for: is_device_parameter

For Device parameters we expect a block device name. However we were only testing for "/dev/..." and so chardevs (from the appliance) could be passed here, resulting in strange effects. This adds a function is_device_parameter which tests for a valid block device name. For Dev_or_Path parameters much the same, except we can also use the is_device_parameter function elsewhere in the daemon to distinguish if we were called with a device or path parameter. Previously we used a simple test if the path begins with "/de...

...(statbuf.st_mode)) { > + fprintf (stderr, "S_ISDIR\n"); The two unconditional fprintf() look like debugging leftovers. > + fd = open (device, O_RDONLY|O_CLOEXEC); > + if (fd == -1) { > + if (verbose) > + fprintf (stderr, "%s: open: %s: %m\n", "is_device_parameter", device); > + return 0; > + } > + if (ioctl (fd, BLKGETSIZE64, &n) == -1) { > + if (verbose) > + fprintf (stderr, "%s: ioctl BLKGETSIZE64: %s: %m\n", > + "is_device_parameter", device); > + close (fd); > + return...

https://bugzilla.redhat.com/show_bug.cgi?id=1477623 The first two patches are cleanups. The third patch changes the way that we handle Device and Dev_or_Path parameters so that a parameter marked as such can really only contain a block device name (and not, for instance, a chardev). Using a chardev here caused hangs in the API. The next two patches fix API usage to conform to this new stricter

v1 was here: https://www.redhat.com/archives/libguestfs/2020-February/msg00220.html This patch series is a little bit better. It's still a bit of a hack. The _real_ fix for this is outlined in the TODO file (see patch 1) but that requires a lot more work than we could do before 1.42 is released, unless we delay 1.42 for a lot longer. I'm hoping with this to have something which works