[Libguestfs] [PATCH 06/10] copy-out: new 'excludes' optional argument

[Pino Toscano]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20170215/dedef0c4/attachment.sig>