search for: nbdkit_realpath

Hi, this is the v3 of my series for nbdkit_realpath; this series adds an extra documentation update to nbdkit_absolute_path, documenting when it can only be used, and then adds nbdkit_realpath. Thanks, Pino Toscano (2): docs: improve documentation of nbdkit_absolute_path plugin: add and use nbdkit_realpath docs/nbdkit-plugin.pod | 24 ++...

...epending the current working directory to the path, with no extra +checks. If conversion was not possible, this calls C<nbdkit_error> and returns C<NULL>. Note that this function does not check that the file exists. The returned string must be freed by the caller. +=head2 C<nbdkit_realpath> + + char *nbdkit_realpath (const char *filename); + +The utility function C<nbdkit_realpath> converts any path to an +absolute path, resolving symlinks. Under the hood it uses the +C<realpath> function, and thus it fails if the path does not exist, +or it is not possible to access...

...ocs/nbdkit-plugin.pod b/docs/nbdkit-plugin.pod index 44822fc..4576635 100644 --- a/docs/nbdkit-plugin.pod +++ b/docs/nbdkit-plugin.pod @@ -207,6 +207,19 @@ C<NULL>. Note that this function does not check that the file exists. The returned string must be freed by the caller. +=head2 C<nbdkit_realpath> + + char *nbdkit_realpath (const char *filename); + +The utility function C<nbdkit_realpath> converts any path to an +absolute path, resolving symlinks. Under the hood, it uses the +C<realpath> function. + +If the path resolution was not possible, this calls C<nbdkit_error> +...

...library if they want to avoid undefined symbols (and to continue to allow the to link with undefined symbols if they choose not to compile against that library)? That is, I'm trying to see what you are considering to be a break between: - what we have now: nbdkit-file-plugin.so: depends on nbdkit_realpath() as undefined symbol nbdkit binary: provides nbdkit_realpath() before dlloading the plugin - building with -no-undefined libnbdkit.so: provides nbdkit_realpath() nbdkit binary: depends on libnbdkit.so, making nbdkit_realpath() available nbdkit-file-plugin.so: depends on libnbdkit.so, so it sees n...

...; > 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...

...d, 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...

...;> 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 >>> --- >>> +char * >>> +nbdkit_realpath (const char *path) >>> +{ >>> + char *ret; >>> + >>> + if (path == NULL || *path == '\0') { >>> + nbdkit_error ("cannot resolve a null or empty path"); >>> + return NULL; >>> + } >>> + >>> +...

On Tue, Mar 24, 2020 at 02:16:32PM -0500, Eric Blake wrote: > On 3/24/20 1:54 PM, Richard W.M. Jones wrote: > >On Tue, Mar 24, 2020 at 01:43:52PM -0500, Eric Blake wrote: > >>On 3/21/20 7:06 AM, Richard W.M. Jones wrote: > >>>Eric: > >>> > >>>Yifan Gu has posted a few patches for mingw support. My comments > >>>below. >

Instead of needing to provide .unload, we can let nbdkit manage the lifetime for us. However, if we like this approach, it may be wiser to introduce new variants of nbdkit_realpath/absolute_path which return const char * already intern'd. Signed-off-by: Eric Blake <eblake@redhat.com> --- See the cover letter: if we like this, there are several other plugins that could also reduce their .unload, or maybe we want to add convenience functions to make the combo 'n...

On 02/13/2018 09:44 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 exist (and thus avoid errors later s/exist/exists/ s/avoid/avoids/ > on). > > Apply it where an existing path is required, both in nbdkit itself and > in

Should we use attribute((nonnull)) at all? There's a very interesting history of this in libvirt -- try looking at commit eefb881 plus the commits referencing eefb881 -- but it does seem to work for me using recent GCC and Clang. I only did a few functions because annotating them gets old quickly... Rich.

...lt values). And of course, if you want to actually implement extents, and figure out how to expose C-based nbdkit functions to be called by Rust code, be my guest (for .zero, we need nbdkit_set_error(), for extents, we need nbdkit_add_extent(), and then we have several other utility functions like nbdkit_realpath() that could be useful). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

...ramping of thread pool. - TRIM support in the file plugin. - nbdkit_parse_size rewritten. - Test IPv6 connections. - Reworked error handling. - New log filter. - New blocksize filter. - New nozero filter. - New fua filter. - New can_zero, can_fua methods and better handling of FUA. - New nbdkit_realpath function. - Better handling of shutdown. - New ext2 plugin. - Bash tab completion. - New zero plugin. - New random plugin. - New PKG_CHECK_VAR variables. - TLS-PSK authentication. - New Tcl plugin (posted for review). - Of course numerous smaller bug fixes and improvements. I'm also g...

...port_description, but this is the promised code showing why nbdkit_string_intern is useful. Patch 4 is somewhat RFC: we could either add new API to take the boilerplate from: foo_config(const char *key, const char *value) { if (strcmp (key, "file") == 0) { CLEANUP_FREE char *tmp = nbdkit_realpath (value); filename = nbdkit_string_intern (tmp); if (!filename) return -1; } ... to the shorter: foo_config(const char *key, const char *value) { if (strcmp (key, "file") == 0) { if ((filename = nbdkit_realpath_intern (value)) == NULL) return -1; } by add...

On 3/24/20 3:12 PM, Eric Blake wrote: >> (For non-mingw platforms) this breaks the source API promises rather >> seriously, so if I understand your proposal correctly I don't think >> this is a good idea.  It's possibly something we can consider for >> internal plugins, or for the V3 API. > > How does it break API to request that someone link against a

...ine. But maybe we want to defer opening this until we actually do list_exports? I can see arguments both ways TBH, one obvious one being that it'd be nice to fail early if directory doesn't exist at all. However if we defer opening the directory til it is needed then we would have to use nbdkit_realpath on the directory name, and that should check that the directory (or something) exists. > + if (directory) { > + const char *exportname = nbdkit_export_name (); > + > + if (strchr (exportname, '/')) { > + nbdkit_error ("exportname cannot contain /"); &gt...

...ename); + free (cmd); + return NULL; +} + static int sh_config (const char *key, const char *value) { @@ -124,7 +169,15 @@ sh_config (const char *key, const char *value) nbdkit_error ("the first parameter must be script=/path/to/script"); return -1; } - script = nbdkit_realpath (value); + + /* If the script name is not "-" then it's expected to be a + * filename, otherwise it's an inline script which must be read + * into a temporary file. Either way we want an absolute path. + */ + if (strcmp (value, "-") != 0) + script...

...ld it still be possible to compile without this? I guess as long as plugins do not start using -no-undefined then it would still work, so it wouldn't be a source API break. I had a look into how we might implement libnbdkit.so. Some functions are obviously self-contained (eg. nbdkit_parse_*, nbdkit_realpath, nbdkit_debug, nbdkit_error, nbdkit_*extents). Unfortunately some functions depend themselves on internals of the server: * nbdkit_nanosleep, nbdkit_export_name, nbdkit_peer_name call threadlocal_get_conn * nbdkit_set_error calls threadlocal_set_error * nbdkit_shutdown must set the quit glo...

...+++ b/include/nbdkit-common.h @@ -40,6 +40,7 @@ #include <stdarg.h> #include <stdint.h> #include <errno.h> +#include <sys/socket.h> #include <nbdkit-version.h> @@ -87,6 +88,7 @@ extern int nbdkit_read_password (const char *value, char **password); extern char *nbdkit_realpath (const char *path); extern int nbdkit_nanosleep (unsigned sec, unsigned nsec); extern const char *nbdkit_export_name (void); +extern int nbdkit_peer_name (struct sockaddr *addr, socklen_t *addrlen); struct nbdkit_extents; extern int nbdkit_add_extent (struct nbdkit_extents *, diff --git a/ser...

...to actually implement extents, and figure out > > how to expose C-based nbdkit functions to be called by Rust code, be my > > guest (for .zero, we need nbdkit_set_error(), for extents, we need > > nbdkit_add_extent(), and then we have several other utility functions > > like nbdkit_realpath() that could be useful). > > Also, we are lacking a tests/*rust* usage; it would be nice if 'make > check' covered a Rust plugin (more than just running 'nbdkit > plugins/rust/target/release/examples/libramdisk.so'). We certainly do need tests for the Rust plugin. Act...