On Tuesday, 14 February 2017 16:28:24 CET Richard W.M. Jones wrote:
On Tue, Feb 14, 2017 at 09:12:07AM +0100, Pino Toscano wrote:
> Add a new 'excludes' optional argument to copy-out, passing it straight
> to tar-out: this way it is possible to exclude files when extracting a
> directory from the guest.
> ---
> generator/actions.ml | 16 ++++++++++++++--
> gobject/Makefile.inc | 2 ++
> lib/copy-in-out.c | 13 ++++++++++---
> 3 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/generator/actions.ml b/generator/actions.ml
> index 990eacb..fd6cc9f 100644
> --- a/generator/actions.ml
> +++ b/generator/actions.ml
> @@ -3437,8 +3437,9 @@ Wildcards cannot be used." };
>
> { defaults with
> name = "copy_out"; added = (1, 29, 24);
> - style = RErr, [Pathname "remotepath"; String "localdir"],
[];
> + style = RErr, [Pathname "remotepath"; String "localdir"],
[OStringList "excludes"];
This change seems reasonable. Should we:
(1) Bind other tar-out parameters? It looks as if numericowner,
xattrs, selinux and acls would all be candidates.
Indeed, I will add them.
(2) More importantly for this patch, keep the order of the options
compatible with tar-out? This would allow us to pass the
optargs_bitmask straight through, if that's an advantage (it may not
be). The 'compressed' optarg for tar-out makes this a bit more
complicated.
Even if the order is the same, we still need to check for the presence
of each bit, copying the right variables from the copy_out optargs
struct to the tar_out one. So in the end the same order will not give
any advantage, I'm afraid.
--
Pino Toscano