You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@subversion.apache.org by Andrey <an...@online-solutions.ru> on 2011/10/18 15:09:52 UTC

Re[2]: Very big problems with access rights (authz file using) in SVN v1.7.0

Hello.

>> We had upgraded from SVN v1.6.5 to SVN v1.7.0, and now we have a
>> really big problems, because SVN v1.7.0 is not working as previous SVN
>> versions and incorrectly working with restrictions for some
>> directories in authz.
>> 
>> A simple example of the issue:
>> 
>> Let's assume this authz file:
>> ===================================================
>> [repos:/PROJECT/trunk/Sample]
>> ax = rw
>> mh = rw
>> lk = rw
>> sa = r
>> ep = rw
>> 
>> [repos:/PROJECT/trunk/Sample/AnyDir/RestrictedDir]
>> ax = rw
>> mh = rw
>> * =
>> ===================================================
>> 
>> SVN v1.6.5 and all clients worked with it in the following manner:
>> 1. They are allowed to use 'svn update' command on the "Sample" directory.
>> 2. They are showed "Sample/AnyDir/RestrictedDir" in repo-browser
>>    (TortoiseSVN GUI), but did not allowed to update/commit or view
>>    content of this directory.
>> 3. There are no any problems to make svn update in any part of the
>>    "/Sample" dir and subdirs using svn client (command line) or any
>>    other (GUI) client.
>> 
>> After upgrading our server to SVN v1.7.0 we had a really big problems,
>> because now when we try to make update in the root directory (/Sample)
>> we see something like:
>> 
>> ==========================================================
>> ==============
>> Updating '.': 13:5
>> Restored 'Sample\AnyDir\RestrictedDir'
>> svn: E155000: Failed to mark
>> 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
>> absent: item of the same name is already scheduled for addition
>> ==========================================================
>> ==============
>> 
>> So, SVN update failed!
>> 
>> No we cannot use our BUILD SERVER, also coders are unable to make SVN
>> UPDATE locally with the same problem!
>> 
>> We have a complicated access rules for different users. Now it does
>> not work AT ALL! Because if some directory is available for user to
>> see that it is exist (it is made to give a possibility to make a
>> commits in a root directory, and do not split commits to a few dirs),
>> he will unable to make svn update in the root -- svn will fail on this
>> directory, that must be easly skipped, as SVN v1.6.5 server/clients
>> done before!
>> 
>> This is a really serious problem for us, we can't work now.

BH> Can you post a simple walkthrough script that describes your exact problem.

BH> By just reading your mail I would guess the script is:

BH> As user lk do:

BH> $ svn co http://server/repos/PROJECT/trunk/Sample sample
BH> $ svn up sample
BH> (repeat the update)

BH> But this simple scenario appears to work correctly for me as it doesn't
BH> check out AnyDir/RestrictedDir in my tests.

BH> The ouput of svn says that you update the directory above 'Sample'.

Users, who have no access to "RestrictedDir" have such local copies
(just sample):

C:/PROJECT/trunk/Sample

C:/PROJECT/trunk/Sample/SomeDirForEveryone
C:/PROJECT/trunk/Sample/SomeDirForEveryone/DummyFile.txt
C:/PROJECT/trunk/Sample/SomeDirForEveryone/DummyFile.bin

C:/PROJECT/trunk/Sample/AnotherDir
C:/PROJECT/trunk/Sample/AnotherDir/DummyFile2.cpp
C:/PROJECT/trunk/Sample/AnotherDir/DummyFile2.h

C:/PROJECT/trunk/Sample/AnyDir
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir/AccessableFile.txt
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir/AccessableFile.bin
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir2
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir2/AccessableFile.txt
C:/PROJECT/trunk/Sample/AnyDir/AccessableDir2/AccessableFile.bin

C:/PROJECT/trunk/Sample/AnotherDir3
C:/PROJECT/trunk/Sample/AnotherDir3/DummyFile2.cpp
C:/PROJECT/trunk/Sample/AnotherDir3/DummyFile2.h

Users (who are restricted to access RestrictedDir) does not have local
copy of
C:/PROJECT/trunk/Sample/AnyDir/RestrictedDir

Previous behaviour (SVN v1.6.5 CollabNet / TortoiseSVN v1.6.15/16/other, prior v1.7.0):
When user use svn update into C:/PROJECT/trunk/Sample directory, it
receives updates for any files/directories of this
directory/subdirectories, EXCLUDING anything, that are subdir/subfiles
for
C:/PROJECT/trunk/Sample/AnyDir/RestrictedDir

Users can see that this directory exist (through repo-browser of
TortoiseSVN, for example), because they have access for RW to /Sample
dir, but most of them (except 'ax' and 'mh') CANNOT list or receive
(read/write) files from/to this directory, because it is restricted by
"* =" rule.

So, it is a perfect way to allow for most users do update and commits
from a root directory (/Sample) (we providing a 'powerful' rights on
root, but removing some rights for restricted dirs only).

But when we using SVN v1.7.0 (console client from the same build as
server; or TortoiseSVN), we had a problem. When user (who is
restricted to access /RestrictedDir) tries to make svn update on the
root dir (/Sample), he got error as I described above.

Updating '.'
Restored 'Sample\AnyDir\RestrictedDir'
svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
absent: item of the same name is already scheduled for addition

SVN does not skip this directory, it creates is locally(!) as empty
directory(!) and stop/fail on svn update after this.

That's all.

(Previous versions just skipped this directory, because they are
checked that user have no access to this directory; they did not
created an empty dirs; just skipped without any errors).

BH> Things I'm interested in are like:

BH> * Do multiple users share a single working copy?

No.

BH> So AnyDir/restricteddir is checked out by one user, but wouldn't be by the
BH> user updating. Or the other way around.

BH> * Is the configuration changed between updates?

No.

BH> Is some change in a specific location required between updates?
BH> E.g.  one in AnyDir, RestrictedDir, etc.

BH> I can see some problems, which might need fixing but I'm still not sure what
BH> your specific problem is.
BH> (I'm not sure if the problems I currently see are regressions. Still looking
BH> into that)

BH> The error you see would only make sense if the working copy doesn't know
BH> about RestrictedDir, except that it is a locally added file or directory.
BH> When the server then tells that there should be a restricted path there you
BH> get this error.

BH> But giving a working copy with a single user, that is +- impossible to read
BH> in your mail.

-- 
С уважением,
 Andrey                          mailto:andrey@online-solutions.ru

RE: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: woensdag 19 oktober 2011 9:26
> To: Bert Huijben
> Cc: Andrey; Stefan Sperling; users@subversion.apache.org
> Subject: Re: Re[4]: Very big problems with access rights (authz file
using) in
> SVN v1.7.0
> 
> On Wed, Oct 19, 2011 at 12:45 AM, Bert Huijben <be...@qqmail.nl> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> >> Sent: woensdag 19 oktober 2011 0:32
> >> To: Bert Huijben
> >> Cc: Andrey; Stefan Sperling; users@subversion.apache.org
> >> Subject: Re: Re[4]: Very big problems with access rights (authz file
> > using) in
> >> SVN v1.7.0
> >>
> >> On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben <be...@qqmail.nl> wrote:
> >> >> -----Original Message-----
> >> >> From: Bert Huijben [mailto:bert@qqmail.nl]
> >> >> Sent: dinsdag 18 oktober 2011 19:43
> >> >> To: 'Andrey'; 'Johan Corveleyn'
> >> >> Cc: 'Stefan Sperling'; users@subversion.apache.org
> >> >> Subject: RE: Re[4]: Very big problems with access rights (authz file
> >> > using) in
> >> >> SVN v1.7.0
> >> >
> >> >> Ok, with that information I reproduced this problem in the
Subversion
> >> test
> >> >> suite on upgrading a working copy with server excluded (or 'absent')
> >> > nodes.
> >> >> After the upgrade updates fail.
> >> >>
> >> >> I will look into fixing this problem tomorrow. (If somebody else
wants
> > to
> >> >> look first, please let me know ;-)
> >> >
> >> > The problem is fixed on trunk and I nominated it for backport.
> >> >
> >> > Please ping your favorite committer to make him review the patch for
> >> > inclusion in 1.7.1 ;)
> >> >
> >> > All upgrades of working copies that contains information on
> > subdirectories
> >> > where the user doesn't have access to, have this same problem. I
think
> > the
> >> > only real way to resolve this issue on a working copy is checking out
> > again.
> >>
> >> Would 'svn up -r0 path/to/restrictedDir' on an
> >> already-upgraded-but-broken-wc also be able to repair it?
> >
> > No, this won't work.
> >
> > This trick relies on receiving the update from the current state to r0
from
> > the server, but you don't have the authorization to get this update from
> the
> > server.
> 
> And 'svn up -r0 path/to/parentOfRestrictedDir'?

This has the same effect as a normal update op parentOfRestricted dir. So
you probably receive a tree conflict (restricted dir is not unmodified)
*and* the failed update (security problem).

	Bert

Re: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0

Posted by Johan Corveleyn <jc...@gmail.com>.

On Wed, Oct 19, 2011 at 12:45 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
>> Sent: woensdag 19 oktober 2011 0:32
>> To: Bert Huijben
>> Cc: Andrey; Stefan Sperling; users@subversion.apache.org
>> Subject: Re: Re[4]: Very big problems with access rights (authz file
> using) in
>> SVN v1.7.0
>>
>> On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben <be...@qqmail.nl> wrote:
>> >> -----Original Message-----
>> >> From: Bert Huijben [mailto:bert@qqmail.nl]
>> >> Sent: dinsdag 18 oktober 2011 19:43
>> >> To: 'Andrey'; 'Johan Corveleyn'
>> >> Cc: 'Stefan Sperling'; users@subversion.apache.org
>> >> Subject: RE: Re[4]: Very big problems with access rights (authz file
>> > using) in
>> >> SVN v1.7.0
>> >
>> >> Ok, with that information I reproduced this problem in the Subversion
>> test
>> >> suite on upgrading a working copy with server excluded (or 'absent')
>> > nodes.
>> >> After the upgrade updates fail.
>> >>
>> >> I will look into fixing this problem tomorrow. (If somebody else wants
> to
>> >> look first, please let me know ;-)
>> >
>> > The problem is fixed on trunk and I nominated it for backport.
>> >
>> > Please ping your favorite committer to make him review the patch for
>> > inclusion in 1.7.1 ;)
>> >
>> > All upgrades of working copies that contains information on
> subdirectories
>> > where the user doesn't have access to, have this same problem. I think
> the
>> > only real way to resolve this issue on a working copy is checking out
> again.
>>
>> Would 'svn up -r0 path/to/restrictedDir' on an
>> already-upgraded-but-broken-wc also be able to repair it?
>
> No, this won't work.
>
> This trick relies on receiving the update from the current state to r0 from
> the server, but you don't have the authorization to get this update from the
> server.

And 'svn up -r0 path/to/parentOfRestrictedDir'?

-- 
Johan

RE: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0

Posted by Bert Huijben <be...@qqmail.nl>.


> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: woensdag 19 oktober 2011 0:32
> To: Bert Huijben
> Cc: Andrey; Stefan Sperling; users@subversion.apache.org
> Subject: Re: Re[4]: Very big problems with access rights (authz file
using) in
> SVN v1.7.0
> 
> On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben <be...@qqmail.nl> wrote:
> >> -----Original Message-----
> >> From: Bert Huijben [mailto:bert@qqmail.nl]
> >> Sent: dinsdag 18 oktober 2011 19:43
> >> To: 'Andrey'; 'Johan Corveleyn'
> >> Cc: 'Stefan Sperling'; users@subversion.apache.org
> >> Subject: RE: Re[4]: Very big problems with access rights (authz file
> > using) in
> >> SVN v1.7.0
> >
> >> Ok, with that information I reproduced this problem in the Subversion
> test
> >> suite on upgrading a working copy with server excluded (or 'absent')
> > nodes.
> >> After the upgrade updates fail.
> >>
> >> I will look into fixing this problem tomorrow. (If somebody else wants
to
> >> look first, please let me know ;-)
> >
> > The problem is fixed on trunk and I nominated it for backport.
> >
> > Please ping your favorite committer to make him review the patch for
> > inclusion in 1.7.1 ;)
> >
> > All upgrades of working copies that contains information on
subdirectories
> > where the user doesn't have access to, have this same problem. I think
the
> > only real way to resolve this issue on a working copy is checking out
again.
> 
> Would 'svn up -r0 path/to/restrictedDir' on an
> already-upgraded-but-broken-wc also be able to repair it?

No, this won't work.

This trick relies on receiving the update from the current state to r0 from
the server, but you don't have the authorization to get this update from the
server.

	Bert

Re: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0

Posted by Johan Corveleyn <jc...@gmail.com>.

On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben <be...@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Bert Huijben [mailto:bert@qqmail.nl]
>> Sent: dinsdag 18 oktober 2011 19:43
>> To: 'Andrey'; 'Johan Corveleyn'
>> Cc: 'Stefan Sperling'; users@subversion.apache.org
>> Subject: RE: Re[4]: Very big problems with access rights (authz file
> using) in
>> SVN v1.7.0
>
>> Ok, with that information I reproduced this problem in the Subversion test
>> suite on upgrading a working copy with server excluded (or 'absent')
> nodes.
>> After the upgrade updates fail.
>>
>> I will look into fixing this problem tomorrow. (If somebody else wants to
>> look first, please let me know ;-)
>
> The problem is fixed on trunk and I nominated it for backport.
>
> Please ping your favorite committer to make him review the patch for
> inclusion in 1.7.1 ;)
>
> All upgrades of working copies that contains information on subdirectories
> where the user doesn't have access to, have this same problem. I think the
> only real way to resolve this issue on a working copy is checking out again.

Would 'svn up -r0 path/to/restrictedDir' on an
already-upgraded-but-broken-wc also be able to repair it?

-- 
Johan

RE: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: dinsdag 18 oktober 2011 19:43
> To: 'Andrey'; 'Johan Corveleyn'
> Cc: 'Stefan Sperling'; users@subversion.apache.org
> Subject: RE: Re[4]: Very big problems with access rights (authz file
using) in
> SVN v1.7.0
 
> Ok, with that information I reproduced this problem in the Subversion test
> suite on upgrading a working copy with server excluded (or 'absent')
nodes.
> After the upgrade updates fail.
> 
> I will look into fixing this problem tomorrow. (If somebody else wants to
> look first, please let me know ;-)

The problem is fixed on trunk and I nominated it for backport.

Please ping your favorite committer to make him review the patch for
inclusion in 1.7.1 ;)

All upgrades of working copies that contains information on subdirectories
where the user doesn't have access to, have this same problem. I think the
only real way to resolve this issue on a working copy is checking out again.

	Bert

RE: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0

Posted by Bert Huijben <be...@qqmail.nl>.


> -----Original Message-----
> From: Andrey [mailto:andrey@online-solutions.ru]
> Sent: dinsdag 18 oktober 2011 15:53
> To: Johan Corveleyn
> Cc: Stefan Sperling; Bert Huijben; users@subversion.apache.org
> Subject: Re[4]: Very big problems with access rights (authz file using) in
SVN
> v1.7.0
> 
> Здравствуйте, Johan.
> 
> Вы писали 18 октября 2011 г., 17:43:48:
> 
> JC> 2011/10/18 Andrey <an...@online-solutions.ru>:
> >> Здравствуйте, Stefan.
> >>
> >> Вы писали 18 октября 2011 г., 17:20:56:
> >>
> >>>> But when we using SVN v1.7.0 (console client from the same build as
> >>>> server; or TortoiseSVN), we had a problem. When user (who is
> >>>> restricted to access /RestrictedDir) tries to make svn update on the
> >>>> root dir (/Sample), he got error as I described above.
> >>>>
> >>>> Updating '.'
> >>>> Restored 'Sample\AnyDir\RestrictedDir'
> >>>> svn: E155000: Failed to mark
> 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
> >>>> absent: item of the same name is already scheduled for addition
> >>>>
> >>>> SVN does not skip this directory, it creates is locally(!) as empty
> >>>> directory(!) and stop/fail on svn update after this.
> >>>>
> >>>> That's all.
> >>
> >> SS> Can you please clarify which versions were running on the client
> >> SS> and which version was running on the server when the problem
> appeared?
> >>
> >> SS> Both running 1.7?
> >> SS> Server 1.6 and clients 1.7?
> >> SS> Clients 1.6 and server 1.7?
> >>
> >> SS> From what you're saying the only thing I understand is that both
> >> SS> 1.6 client and 1.6 server was working.
> >>
> >> All for users, who have no access to restricted dir:
> >>
> >> 1. Server: SVN v1.7.0 (WANdisco build)
> >>   Client: TortoiseSVN v1.7.0
> >>
> >>   NOT WORKING (update problem; empty directory created, update
> failed)
> >>
> >> 2. Server: SVN v1.7.0 (WANdisco build)
> >>   Client: Console SVN v1.7.0 (WANdisco build)
> >>
> >>   NOT WORKING (update problem; empty directory created, update
> failed)
> >>
> >> 3. Server: SVN v1.7.0 (WANdisco build)
> >>   Client: TortoiseSVN v1.6.15 (Subversion v1.6.16)
> >>
> >>   [!] WORKING as previous behaviour!
> >>
> >> So, the problem is really inside CLIENT interpretation of server
> >> statuses. Both new version of console svn.exe (svn client) and
> >> TortoiseSVN working incorrectly now.
> 
> JC> Is it broken only for working copies that were upgraded from 1.6 to
> JC> 1.7, or also for new checkouts done with your 1.7 client?
> 
> JC> I'm wondering if it's a bug in the upgrade code (server-excluded nodes
> JC> being incorrectly upgraded), or in the general handling of
> JC> server-exluded nodes in 1.7.
> 
> Yes, you are right, it is a bug with upgrade procedure.
> 
> I made an expirement:
> 
> 1. Made a clean checkout to a new place on a computer of user with
>    restricted access. Checkout was without any problem.
> 2. After this I tried to make svn update -- all was fine.
> 3. After this from my computer I made a "cross" commit (one commit
>    includes a change to a files, where users have no access, and to a
>    files accessed by them).
>    I used SVN update on root directory on restricted-users -- all was
>    fine.
> 
> So, if a clean checkout (without upgrade) is made, there is no such
> problem.

Ok, with that information I reproduced this problem in the Subversion test
suite on upgrading a working copy with server excluded (or 'absent') nodes.
After the upgrade updates fail.

I will look into fixing this problem tomorrow. (If somebody else wants to
look first, please let me know ;-)

	Bert

Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0

Posted by Andrey <an...@online-solutions.ru>.

Здравствуйте, Johan.

Вы писали 18 октября 2011 г., 17:43:48:

JC> 2011/10/18 Andrey <an...@online-solutions.ru>:
>> Здравствуйте, Stefan.
>>
>> Вы писали 18 октября 2011 г., 17:20:56:
>>
>>>> But when we using SVN v1.7.0 (console client from the same build as
>>>> server; or TortoiseSVN), we had a problem. When user (who is
>>>> restricted to access /RestrictedDir) tries to make svn update on the
>>>> root dir (/Sample), he got error as I described above.
>>>>
>>>> Updating '.'
>>>> Restored 'Sample\AnyDir\RestrictedDir'
>>>> svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
>>>> absent: item of the same name is already scheduled for addition
>>>>
>>>> SVN does not skip this directory, it creates is locally(!) as empty
>>>> directory(!) and stop/fail on svn update after this.
>>>>
>>>> That's all.
>>
>> SS> Can you please clarify which versions were running on the client
>> SS> and which version was running on the server when the problem appeared?
>>
>> SS> Both running 1.7?
>> SS> Server 1.6 and clients 1.7?
>> SS> Clients 1.6 and server 1.7?
>>
>> SS> From what you're saying the only thing I understand is that both
>> SS> 1.6 client and 1.6 server was working.
>>
>> All for users, who have no access to restricted dir:
>>
>> 1. Server: SVN v1.7.0 (WANdisco build)
>>   Client: TortoiseSVN v1.7.0
>>
>>   NOT WORKING (update problem; empty directory created, update failed)
>>
>> 2. Server: SVN v1.7.0 (WANdisco build)
>>   Client: Console SVN v1.7.0 (WANdisco build)
>>
>>   NOT WORKING (update problem; empty directory created, update failed)
>>
>> 3. Server: SVN v1.7.0 (WANdisco build)
>>   Client: TortoiseSVN v1.6.15 (Subversion v1.6.16)
>>
>>   [!] WORKING as previous behaviour!
>>
>> So, the problem is really inside CLIENT interpretation of server
>> statuses. Both new version of console svn.exe (svn client) and
>> TortoiseSVN working incorrectly now.

JC> Is it broken only for working copies that were upgraded from 1.6 to
JC> 1.7, or also for new checkouts done with your 1.7 client?

JC> I'm wondering if it's a bug in the upgrade code (server-excluded nodes
JC> being incorrectly upgraded), or in the general handling of
JC> server-exluded nodes in 1.7.

Yes, you are right, it is a bug with upgrade procedure.

I made an expirement:

1. Made a clean checkout to a new place on a computer of user with
   restricted access. Checkout was without any problem.
2. After this I tried to make svn update -- all was fine.
3. After this from my computer I made a "cross" commit (one commit
   includes a change to a files, where users have no access, and to a
   files accessed by them).
   I used SVN update on root directory on restricted-users -- all was
   fine.
   
So, if a clean checkout (without upgrade) is made, there is no such
problem.

-- 
С уважением,
 Andrey                          mailto:andrey@online-solutions.ru

Re: Re[2]: Very big problems with access rights (authz file using) in SVN v1.7.0

Posted by Johan Corveleyn <jc...@gmail.com>.

2011/10/18 Andrey <an...@online-solutions.ru>:
> Здравствуйте, Stefan.
>
> Вы писали 18 октября 2011 г., 17:20:56:
>
>>> But when we using SVN v1.7.0 (console client from the same build as
>>> server; or TortoiseSVN), we had a problem. When user (who is
>>> restricted to access /RestrictedDir) tries to make svn update on the
>>> root dir (/Sample), he got error as I described above.
>>>
>>> Updating '.'
>>> Restored 'Sample\AnyDir\RestrictedDir'
>>> svn: E155000: Failed to mark 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir'
>>> absent: item of the same name is already scheduled for addition
>>>
>>> SVN does not skip this directory, it creates is locally(!) as empty
>>> directory(!) and stop/fail on svn update after this.
>>>
>>> That's all.
>
> SS> Can you please clarify which versions were running on the client
> SS> and which version was running on the server when the problem appeared?
>
> SS> Both running 1.7?
> SS> Server 1.6 and clients 1.7?
> SS> Clients 1.6 and server 1.7?
>
> SS> From what you're saying the only thing I understand is that both
> SS> 1.6 client and 1.6 server was working.
>
> All for users, who have no access to restricted dir:
>
> 1. Server: SVN v1.7.0 (WANdisco build)
>   Client: TortoiseSVN v1.7.0
>
>   NOT WORKING (update problem; empty directory created, update failed)
>
> 2. Server: SVN v1.7.0 (WANdisco build)
>   Client: Console SVN v1.7.0 (WANdisco build)
>
>   NOT WORKING (update problem; empty directory created, update failed)
>
> 3. Server: SVN v1.7.0 (WANdisco build)
>   Client: TortoiseSVN v1.6.15 (Subversion v1.6.16)
>
>   [!] WORKING as previous behaviour!
>
> So, the problem is really inside CLIENT interpretation of server
> statuses. Both new version of console svn.exe (svn client) and
> TortoiseSVN working incorrectly now.

Is it broken only for working copies that were upgraded from 1.6 to
1.7, or also for new checkouts done with your 1.7 client?

I'm wondering if it's a bug in the upgrade code (server-excluded nodes
being incorrectly upgraded), or in the general handling of
server-exluded nodes in 1.7.

-- 
Johan