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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
