On 02/14/2018 10:53 AM, Pino Toscano wrote:
Introduce a new helper function to resolve a path name, calling
nbdkit_error on failure: other than doing what nbdkit_absolute_path
does, it also checks that the file exists (and thus avoids errors later
on). To help distinguish it from nbdkit_absolute_path, improve the
documentation of the latter.
Apply it where an existing path is required, both in nbdkit itself and
in plugins.
Related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1527334
---
+++ b/src/utils.c
@@ -228,3 +228,22 @@ nbdkit_read_password (const char *value, char **password)
return 0;
}
+
+char *
+nbdkit_realpath (const char *path)
+{
+ char *ret;
+
+ if (path == NULL || *path == '\0') {
+ nbdkit_error ("cannot resolve a null or empty path");
+ return NULL;
+ }
+
+ ret = realpath (path, NULL);
Wait. Does this even work? Remember, in nbdkit_absolute_path(), we are
prepending get_current_dir_name() (why the GNU spelling, instead of
getcwd(NULL, 0), since either way is a GNU extension?). But in main.c,
we call an unconditional chdir("/") as part of fork_into_background,
which has the annoying result that when using 'nbdkit -f' you honor your
current $PWD, but when running in the background, relative filenames are
now parsed against /. Shouldn't we fix it so that nbdkit saves off
getcwd() up front, prior to fork_into_background, and then both
nbdkit_absolute_path() and nbdkit_realpath() convert any relative names
into something relative to the ORIGINAL working directory, regardless of
foreground or background operation?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org