Hi,

Jeffrey J. Kosowsky wrote on 2011-07-03 20:18:07 -0400 [Re: [BackupPC-users] 
Yet another filesystem thread]:
> Holger Parplies wrote at about 19:31:14 +0200 on Sunday, July 3, 2011:
>  > While the comments in config.pl state
>  > 
>  > # This can be set to a string, an array of strings, or, in the case
>  > # of multiple shares, a hash of strings or arrays.
>  > 
>  > that is actually incorrect. A hash of strings makes no sense. In fact, Perl
>  > would turn your example into a hash with "/proc" and "/pub" as keys and
>  > "/blaat" and "/tmp" as respective values - certainly not what you want.
>  > [...]
> 
> I think by hash of strings, the following is meant:
> $Conf {BackupFilesExclude} = { 'share1' => 'exclude-path1',
>                                'share2' => 'exclude-path2',
>                                 ...
>                              }
> 
> This is just a simpler case of the hash of arrays that you illustrate
> below.

in fact, it's the same as what I meant to illustrate above, and in fact, it's
wrong.

Rereading the code for BackupPC::Lib::backupFileConfFix yet again, I'm quite
sure it doesn't do anything meaningful for a "hash of strings". For the case
of BackupFiles{Exclude,Only} already being a hash, the values are, in fact,
*not* promoted to arrays if they are scalars. Later on (at least in
Xfer::Rsync - I didn't check the other XferMethods), they are used as array
refs:

        foreach my $file ( @{$conf->{BackupFilesExclude}{$t->{shareName}}} )

In absense of 'strict refs', this appears to yield an empty array, which is
preferable to a syntax error, but effectively (and silently) behaves as if
the excludes (or includes) were not specified at all. So, yes, you *can*
specify a hash of strings, but, no, they won't be used as excludes (or
includes).

Before we get into a discussion whether this should be "fixed", and because I
had already written this before I realized that it doesn't currently work this
way:

The point is that it's not "a hash of strings", it's "a hash of key-value
pairs". "A hash of strings" suggests just what the original poster understood:
several strings of the same meaning, excludes probably. I was first going to
say that it's actually a string of share names (with empty exclude lists,
which makes no sense), when I realized that that's not true. Unless you write
it with "=>" (which, in Perl, is simply a synonym for ","), it's anything but
obvious. Perl won't mind if you write

        $Conf {BackupFilesExclude} = { 'share1',
                                       'exclude-path1' => 'share2',
                                       'exclude-path2', ...
                                     };

but it's misleading, just as it is with commas only. The interpretation is
"key-value pairs", so it should be stated explicitly that that's what you
[would] need to supply.

I wonder if the case of only a single exclude pattern per share for all shares
is common enough to warrant advocating its usage [or rather implementing it].
Of course, a mixed usage [would then] also work:

        $Conf {BackupFilesExclude} = { 'share1' => 'exclude1',
                                       'share2' => [ 'exclude2a', 'exclude2b' ],
                                       'share3' => 'exclude3',
                                     };

But who would write that or encourage others to do so? What's the point in
leaving out the '[]' here? Allowing one single array of excludes to apply to
all shares (array value) makes sense, and extending that to allow one single
exclude pattern to apply to all shares (scalar value) also. Both are
simplifications for people not familiar with Perl syntax. Allowing a single
hash of strings would not be a simplification (in my opinion, at least).
Well, your opinion may vary ;-).

> While I have not tried that syntax, I imagine that is what the
> documentation refers to.

I haven't tried it either, obviously.

> Of course, the wording is not terribly clear except maybe to those who
> already know what is going on (and understand perl)...

Well, it would seem to confuse even those ;-).

Either the wording or the implementation needs to be changed. My suggestion is
to change the documentation to:

# This can be set to a string, an array of strings, or, in the case
# of multiple shares, a hash of (string, array) pairs.

I can't see the need for supporting a "hash of strings" variant.

Regards,
Holger

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/