Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id B7B56200C7D for ; Tue, 16 May 2017 15:40:02 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id B59EB160BAC; Tue, 16 May 2017 13:40:02 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 5B742160B9D for ; Tue, 16 May 2017 15:40:01 +0200 (CEST) Received: (qmail 91489 invoked by uid 500); 16 May 2017 13:40:00 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 91477 invoked by uid 99); 16 May 2017 13:40:00 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 May 2017 13:40:00 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id CF2441812EA for ; Tue, 16 May 2017 13:39:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=wandisco.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 93dPmXiEceWH for ; Tue, 16 May 2017 13:39:55 +0000 (UTC) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id BF28C60D1D for ; Tue, 16 May 2017 13:39:54 +0000 (UTC) Received: by mail-io0-f180.google.com with SMTP id p24so93481788ioi.0 for ; Tue, 16 May 2017 06:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wandisco.com; s=gapps; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=84H9hMjCEXYmbpKWqA1dZDXlmkODx8N+146A69EMAqM=; b=UIp5ooA08p2kwUKLe7PCYV5vHtB1Ws2mDCcOdZm4x/yJYu7PLRlezI4bqMGXUMB4Td TeznF4yxSpjouxCvxrh2BAEsO2tUyVnxuRpUU9FsAhGqYvNJVJLcx/Eh8ZXi/h4Ko3ZK L/HrZPmufXqa2OowZhmVcFwFiscvFbomzeP7Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=84H9hMjCEXYmbpKWqA1dZDXlmkODx8N+146A69EMAqM=; b=eZmowy7G19O3T4q15pR6bTf2TQu+oVB2GCmPSKCtOWnNzBCPaN7NIuEK4V7QgbTJdw W2Pvqe9AJ9Hg+aZhJukbWKnuky3OaRxkyBzW0e1bBI9kU6QBRYVxPDJwvdunVlBugQ7e yi4GZO2YoYkcqONAd6jnhp4VmDnFp5WVmLjC8ISNOLr3jYsqGHZpYFa5Ru6VNlIIEr7J 3azVVw2Cozb6D/vBbf9jLgDNzryU8DCL8zFFBAY/iSd1j6Oc0OT+Rf+DJp7NdHcdxwrd eXjc79t6PIATfLUXwL6kyi8LPc6cbTja6R1jWBfKecgk+JjLhU+hj/FFvUxCgXOOY8KO h02Q== X-Gm-Message-State: AODbwcAm2HWjFzgULZV7ti4fvwVjty8X7S/SdYHDASpsU8htuSdpq6Au 88CijKfmT3DcHGocO6n0C+EnPNgpTR4VTKeOBNCwhfv++YjdyiayxPASmAb9dykpddhDayBe4VM 0GmHxqxmNCQnMQ7H65xk= X-Received: by 10.107.20.139 with SMTP id 133mr10729589iou.225.1494941993373; Tue, 16 May 2017 06:39:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.144.90 with HTTP; Tue, 16 May 2017 06:39:52 -0700 (PDT) In-Reply-To: References: <20170315095557.GA4388@fujitsu.shahaf.local2> <4d11690a-7429-f707-44f6-d09a65328658@apache.org> <20170418010823.GB6124@fujitsu.shahaf.local2> <20170501180549.GA5359@fujitsu.shahaf.local2> <20170504081616.GA16987@fujitsu.shahaf.local2> From: Doug Robinson Date: Tue, 16 May 2017 09:39:52 -0400 Message-ID: Subject: Re: wildcard authz docs question To: Johan Corveleyn Cc: Daniel Shahaf , Subversion Development Content-Type: multipart/alternative; boundary="001a114faaf879e7cf054fa44e39" archived-at: Tue, 16 May 2017 13:40:02 -0000 --001a114faaf879e7cf054fa44e39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Johan, et. al.: Solid discussion - thank you. As I said, I'll keep a watch as things progress... Cheers. Doug On Wed, May 10, 2017 at 5:37 PM, Johan Corveleyn wrote: > On Wed, May 10, 2017 at 5:40 PM, Doug Robinson > wrote: > > > > Johan: > > > > Sorry for my sporadic replies... bin a bit hectic here. > > > > Reply buried deep below. > > > > On Fri, May 5, 2017 at 5:09 AM, Johan Corveleyn > wrote: > >> > >> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson > >> wrote: > >> > > >> > Johan: > >> > > >> > (sorry for the empty message - dwim failed) > >> > > >> > On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn > wrote: > >> >> > >> >> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf < > d.s@daniel.shahaf.name> wrote: > >> >> > Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400: > >> >> ... > >> >> >> Not seeing it - at least not yet. In Perl the RE needed to hand= le > >> >> >> this would be one of the duals, e.g. "/trunk/iota(|/.*)" - the > >> >> >> either/or with nothing on the left and "/.*" on the right. It > really > >> >> >> is a dual case. I know of no better syntax. Since we're workin= g > on > >> >> >> this as a wildcard I don't see an alternative. > >> >> > > >> >> > Off the top of my head, we could have [/trunk/iota/***] and > >> >> > [/trunk/iota/**] with different meanings (the former applies to > >> >> > a /trunk/iota file, the latter doesn't). Does anyone else > (besides Doug > >> >> > and I) have ideas here? > >> >> > >> >> Hmm, /*** doesn't look like something I'd remember easily, if I > wanted > >> >> to use that feature as an svn admin. > >> >> > >> >> I have only followed this discussion from a distance. If I understa= nd > >> >> correctly the remaining point is whether or not /iota/** would matc= h > >> >> with the file /iota or not. Speaking purely from my own intuition, = I > >> >> would say "no". I feel this pattern is intended to apply to the > >> >> _subtree_ below iota, including iota itself (which is thus implied = to > >> >> be a directory, because we're talking about subtrees). In practice = I > >> >> think the admin configuring this rule will know whether iota is eve= r > >> >> intended to be a file or a directory. A rule like that to me always > >> >> implies that "the guy who configured it" expects iota to be a > >> >> directory (why else would he put a "subtree rule" for it). > >> >> > >> >> TBH, I also don't really see the use case of "I want this rule to > >> >> apply to the _namespace_ iota, i.e. to the file iota (if it's a fil= e) > >> >> and to directory iota and its subtree (if it's a directory)". In > >> >> context, you always know whether it's meant to be a file or a > >> >> directory. > >> > > >> > > >> > The use case is exactly that some administrator wants to reserve > >> > the namespace. They do not want some sly person to create a file > >> > where they will, at some point in the future, create a directory. I= t > will > >> > be sad that we can't have a simple way to make this reservation, but= , > >> > as I noted above, short of the current "[:glob:/iota/**]" doing the > job it > >> > will take 2 stanzas. > >> > > >> >> > >> >> Maybe we should just follow what most other implementations do? > >> >> I've done a quick check in Atlassian FishEye / Crucible (searching > for > >> >> files). There /iota/** does not match file /iota (but it does match > >> >> directory /iota). > >> > > >> > > >> > The FishEye reference I found does not have a "**" operator - just a > "*" > >> > operator (https://confluence.atlassian.com/jiracoreserver073/search- > syntax-for-text-fields-861257223.html). > >> > > >> > For all cases where a tool has a "*" operator this is semantically > going > >> > to "not match" this use case since the "*" operator that has been > >> > implemented in SVN (at least so far) does not span past a single > >> > directory entry. > >> > >> Ah. No, I'm referring to this syntax in FishEye: > >> https://confluence.atlassian.com/fisheye/pattern-matching- > guide-298976797.html > >> > >> Unfortunately the document does not specify the cases we're interested > >> in here. But I've tested them on our own FishEye instance :-). In this > >> case "/dir/**" does return /dir, but "/file/**" does not return /file. > >> But okay, it's just one example. > >> > >> In the FishEye doc they say they're doing their pattern mathing "same > >> as the pattern matching in Apache Ant". So I've checked ant as well. > >> On this page: > >> > >> https://ant.apache.org/manual/dirtasks.html#patterns > >> > >> at the bottom of the table they say: > >> **/test/** - Matches all files that have a test element in their > >> path, including test as a filename. > >> > >> So I've done a little test in ant (see [1]): apparently "**/test/**" > >> will match the file test, but "/test/**" doesn't! Weird. Apparently > >> the same goes for FishEye, if I put "**/" at the beginning of the > >> pattern, it does match the file. > >> > >> Now, getting back to your use case: "reserving a namespace for future > >> use" (i.e. for now we don't know whether "iota" will ever be a file or > >> a directory, but in any case we don't want anyone to put anything > >> there). To me it sounds like a very special use case. It seems to be > >> something specific for authorization syntaxes, but much less > >> applicable to searching existing filesystems (like glob patterns for > >> shells or tools like FishEye). So maybe it's not such a good idea to > >> look at those tools for inspiration anyway :-). > >> > >> Doug: do you think this is a common use case? Do other authorization > >> systems offer this functionality in an easily configurable manner? I > >> accept this is a valid use case, but it's not one that I would think > >> of using (wearing my hat of svn admin) -- I focus on authorization of > >> the existing files / directories. > > > > > > It's a very common use case. Think of it in terms of allocating all > release > > branches to the release team. Or all Quality Assurance tags to the QA > team. > > OK > > >> > >> Come to think of it: if reserving a namespace for future use, and > >> "/iota" doesn't exist yet, can't you just block the name "/iota" > >> without glob pattern? It doesn't exist anyway, so if you'd like to > >> create some subtree under it, you first have to create /iota, right? > > > > > > There's 2 problems with this: > > > > 1. You're not trying to block the name "/iota", you're giving out privs > to the > > right team for creating (and nobody else). > > > > 2. The "**" operator is very special in that it does a "direct match" o= f > all > > at or below. That "direct match", in terms of wildcards, means that > there > > is no "recursing upwards" to find a parent rule. It's matched > immediately. > > > > Consider multiple repositories in an organization (perhaps they have co= de > > that cannot go to vendors with which they share some repos so they cann= ot > > keep all of their projects within a single repo - or similar use case). > A global > > policy would have identical rules for all repositories. They can't kno= w > when > > or if some subset of the repositories have the specific artifact or not= . > > It would be nice/handy/convenient if a single rule could do the > reservation > > rather than a pair. > > Okay, thanks for clarifying. It's all starting to make sense to me now :-= ). > > So the "reserve namespace" usecase is common and important, and it > sounds very sensible to want to do this with a single rule. And the > "**" matching is better at doing this than the "/iota" rule. Got it. > > >> Now, in the end, I don't want this issue to be blocked forever :-). I > >> think in practice the confusion will be minimal, because either the > >> administrator knows what kind of item "iota" is (a file or a > >> directory), or the item doesn't exist yet and he'll be doing the > >> "reserve namespace" use case. So for me it's fine if "/iota/**" > >> effectively matches both the "directory iota and its subtree" and "the > >> file iota". As long as it's documented that way then :-). > > > > > > My document does that since that is the way that the branched > > implementation for SVN 1.8 and 1.9 works today. > > Great. > > >> If Daniel insists, I'm fine with using "/***" as well, if we want to > >> have this special "reserve namespace" meaning. > > > > > > If so then we'll need to make sure to document the required changes to > > our user's who are using the feature now. It's not a big deal but will > be > > critical when our users upgrade to SVN 1.10. So I'll continue to watch > > this space carefully. > > As Daniel said, he doesn't insist :-) ... I misinterpreted that. And > given that "/**" is already in use by your users as well as others > that have already used the branched implementation > (branches/authzperf), I see no reason to make things more difficult > for little to no gain. So let's leave things like that. > > Thanks for your patience in discussing this. > > -- > Johan > --=20 *DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER T +1 925 396 1125 *E* doug.robinson@wandisco.com --=20 World Leader in Active Data Replication=E2=84=A2 *Find out more wandisco.com * THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE= =20 PRIVILEGED If this message was misdirected, WANdisco, Inc. and its subsidiaries,=20 ("WANdisco") does not waive any confidentiality or privilege. If you are=20 not the intended recipient, please notify us immediately and destroy the=20 message without disclosing its contents to anyone. Any distribution, use or= =20 copying of this email or the information it contains by other than an=20 intended recipient is unauthorized. The views and opinions expressed in=20 this email message are the author's own and may not reflect the views and= =20 opinions of WANdisco, unless the author is authorized by WANdisco to=20 express such views or opinions on its behalf. All email sent to or from=20 this address is subject to electronic storage and review by WANdisco.=20 Although WANdisco operates anti-virus programs, it does not accept=20 responsibility for any damage whatsoever caused by viruses being passed. --001a114faaf879e7cf054fa44e39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Johan, et. al.:

Solid discussion - than= k you.=C2=A0 As I said, I'll keep a watch as things progress...

Cheers.

Doug

On Wed, May 10, 2017 at 5= :37 PM, Johan Corveleyn <jcorvel@gmail.com> wrote:
On Wed, May 10, 2017 at 5:40 PM, Doug Robinson
<do= ug.robinson@wandisco.com> wrote:
>
> Johan:
>
> Sorry for my sporadic replies... bin a bit hectic here.
>
> Reply buried deep below.
>
> On Fri, May 5, 2017 at 5:09 AM, Johan Corveleyn <jcorvel@gmail.com> wrote:
>>
>> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
>> <doug.robinson@wa= ndisco.com> wrote:
>> >
>> > Johan:
>> >
>> > (sorry for the empty message - dwim failed)
>> >
>> > On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jcorvel@gmail.com> wrote:
>> >>
>> >> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: >> >> > Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50= -0400:
>> >> ...
>> >> >> Not seeing it - at least not yet.=C2=A0 In Perl = the RE needed to handle
>> >> >> this would be one of the duals, e.g. "/trun= k/iota(|/.*)" - the
>> >> >> either/or with nothing on the left and "/.*= " on the right.=C2=A0 It really
>> >> >> is a dual case.=C2=A0 I know of no better syntax= .=C2=A0 Since we're working on
>> >> >> this as a wildcard I don't see an alternativ= e.
>> >> >
>> >> > Off the top of my head, we could have [/trunk/iota/*= **] and
>> >> > [/trunk/iota/**] with different meanings (the former= applies to
>> >> > a /trunk/iota file, the latter doesn't).=C2=A0 D= oes anyone else (besides Doug
>> >> > and I) have ideas here?
>> >>
>> >> Hmm, /*** doesn't look like something I'd remembe= r easily, if I wanted
>> >> to use that feature as an svn admin.
>> >>
>> >> I have only followed this discussion from a distance. If = I understand
>> >> correctly the remaining point is whether or not /iota/** = would match
>> >> with the file /iota or not. Speaking purely from my own i= ntuition, I
>> >> would say "no". I feel this pattern is intended= to apply to the
>> >> _subtree_ below iota, including iota itself (which is thu= s implied to
>> >> be a directory, because we're talking about subtrees)= . In practice I
>> >> think the admin configuring this rule will know whether i= ota is ever
>> >> intended to be a file or a directory. A rule like that to= me always
>> >> implies that "the guy who configured it" expect= s iota to be a
>> >> directory (why else would he put a "subtree rule&quo= t; for it).
>> >>
>> >> TBH, I also don't really see the use case of "I = want this rule to
>> >> apply to the _namespace_ iota, i.e. to the file iota (if = it's a file)
>> >> and to directory iota and its subtree (if it's a dire= ctory)". In
>> >> context, you always know whether it's meant to be a f= ile or a
>> >> directory.
>> >
>> >
>> > The use case is exactly that some administrator wants to rese= rve
>> > the namespace.=C2=A0 They do not want some sly person to crea= te a file
>> > where they will, at some point in the future, create a direct= ory.=C2=A0 It will
>> > be sad that we can't have a simple way to make this reser= vation, but,
>> > as I noted above, short of the current "[:glob:/iota/**]= " doing the job it
>> > will take 2 stanzas.
>> >
>> >>
>> >> Maybe we should just follow what most other implementatio= ns do?
>> >> I've done a quick check in Atlassian FishEye / Crucib= le (searching for
>> >> files). There /iota/** does not match file /iota (but it = does match
>> >> directory /iota).
>> >
>> >
>> > The FishEye reference I found does not have a "**" = operator - just a "*"
>> > operator (https://confluence.atlassian.com/jiracoreserver073/= search-syntax-for-text-fields-861257223.html).
>> >
>> > For all cases where a tool has a "*" operator this = is semantically going
>> > to "not match" this use case since the "*"= ; operator that has been
>> > implemented in SVN (at least so far) does not span past a sin= gle
>> > directory entry.
>>
>> Ah. No, I'm referring to this syntax in FishEye:
>> https://confl= uence.atlassian.com/fisheye/pattern-matching-guide-298976797.html=
>>
>> Unfortunately the document does not specify the cases we're in= terested
>> in here. But I've tested them on our own FishEye instance :-).= In this
>> case "/dir/**" does return /dir, but "/file/**"= ; does not return /file.
>> But okay, it's just one example.
>>
>> In the FishEye doc they say they're doing their pattern mathin= g "same
>> as the pattern matching in Apache Ant". So I've checked a= nt as well.
>> On this page:
>>
>>=C2=A0 =C2=A0 =C2=A0https://ant.apache.o= rg/manual/dirtasks.html#patterns
>>
>> at the bottom of the table they say:
>>=C2=A0 =C2=A0 =C2=A0**/test/** - Matches all files that have a test= element in their
>> path, including test as a filename.
>>
>> So I've done a little test in ant (see [1]): apparently "= **/test/**"
>> will match the file test, but "/test/**" doesn't! We= ird. Apparently
>> the same goes for FishEye, if I put "**/" at the beginni= ng of the
>> pattern, it does match the file.
>>
>> Now, getting back to your use case: "reserving a namespace fo= r future
>> use" (i.e. for now we don't know whether "iota"= will ever be a file or
>> a directory, but in any case we don't want anyone to put anyth= ing
>> there). To me it sounds like a very special use case. It seems to = be
>> something specific for authorization syntaxes, but much less
>> applicable to searching existing filesystems (like glob patterns f= or
>> shells or tools like FishEye). So maybe it's not such a good i= dea to
>> look at those tools for inspiration anyway :-).
>>
>> Doug: do you think this is a common use case? Do other authorizati= on
>> systems offer this functionality in an easily configurable manner?= I
>> accept this is a valid use case, but it's not one that I would= think
>> of using (wearing my hat of svn admin) -- I focus on authorization= of
>> the existing files / directories.
>
>
> It's a very common use case.=C2=A0 Think of it in terms of allocat= ing all release
> branches to the release team.=C2=A0 Or all Quality Assurance tags to t= he QA team.

OK

>>
>> Come to think of it: if reserving a namespace for future use, and<= br> >> "/iota" doesn't exist yet, can't you just block = the name "/iota"
>> without glob pattern? It doesn't exist anyway, so if you'd= like to
>> create some subtree under it, you first have to create /iota, righ= t?
>
>
> There's 2 problems with this:
>
> 1. You're not trying to block the name "/iota", you'= re giving out privs to the
> right team for creating (and nobody else).
>
> 2. The "**" operator is very special in that it does a "= ;direct match" of all
> at or below.=C2=A0 That "direct match", in terms of wildcard= s, means that there
> is no "recursing upwards" to find a parent rule.=C2=A0 It= 9;s matched immediately.
>
> Consider multiple repositories in an organization (perhaps they have c= ode
> that cannot go to vendors with which they share some repos so they can= not
> keep all of their projects within a single repo - or similar use case)= .=C2=A0 A global
> policy would have identical rules for all repositories.=C2=A0 They can= 't know when
> or if some subset of the repositories have the specific artifact or no= t.
> It would be nice/handy/convenient if a single rule could do the reserv= ation
> rather than a pair.

Okay, thanks for clarifying. It's all starting to make sense to = me now :-).

So the "reserve namespace" usecase is common and important, and i= t
sounds very sensible to want to do this with a single rule. And the
"**" matching is better at doing this than the "/iota" = rule. Got it.

>> Now, in the end, I don't want this issue to be blocked forever= :-). I
>> think in practice the confusion will be minimal, because either th= e
>> administrator knows what kind of item "iota" is (a file = or a
>> directory), or the item doesn't exist yet and he'll be doi= ng the
>> "reserve namespace" use case. So for me it's fine if= "/iota/**"
>> effectively matches both the "directory iota and its subtree&= quot; and "the
>> file iota". As long as it's documented that way then :-).=
>
>
> My document does that since that is the way that the branched
> implementation for SVN 1.8 and 1.9 works today.

Great.

>> If Daniel insists, I'm fine with using "/***" as wel= l, if we want to
>> have this special "reserve namespace" meaning.
>
>
> If so then we'll need to make sure to document the required change= s to
> our user's who are using the feature now.=C2=A0 It's not a big= deal but will be
> critical when our users upgrade to SVN 1.10.=C2=A0 So I'll continu= e to watch
> this space carefully.

As Daniel said, he doesn't insist :-) ... I misinterpreted that.= And
given that "/**" is already in use by your users as well as other= s
that have already used the branched implementation
(branches/authzperf), I see no reason to make things more difficult
for little to no gain. So let's leave things like that.

Thanks for your patience in discussing this.

--
Johan



--
DOUGL= AS B ROBINSON= =C2=A0SENIOR PRODUCT MANAGER

World Leader in=C2=A0Active Data Replication=E2=84=A2
Find ou= t more=C2=A0wandisco.com

THIS MESSAG= E AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, (&qu= ot;WANdisco") does not waive any confidentiality or privilege. If you = are not the intended recipient, please notify us immediately and destroy th= e message without disclosing its contents to anyone. Any distribution, use = or copying of this email or the information it contains by other than an in= tended recipient is unauthorized. The views and opinions expressed in this = email message are the author's own and may not reflect the views and op= inions of WANdisco, unless the author is authorized by WANdisco to express = such views or opinions on its behalf. All email sent to or from this addres= s is subject to electronic storage and review by WANdisco. Although WANdisc= o operates anti-virus programs, it does not accept responsibility for any d= amage whatsoever caused by viruses being passed.

--001a114faaf879e7cf054fa44e39--