Re: Access denied error on checkout-commit after updating to 1.9.X

[Ivan Zhakov <iv...@visualsvn.com>]

[Moving to dev@s.a.o]

On 4 September 2015 at 18:15, Daniele Pedroni
<pe...@zapispa.it> wrote:
> After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN
> as well as command line throw the following error after trying to checkout
> or commit a Working Directory on a network share:
>
> Commit failed (details follow):
> Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to
>
> 'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base':
>  Access is denied.
>
> (full discussion on TSVN mailing list here:
> https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U )
>
> It seems to be a Subversion issue, not a TortoiseSVN one, since command line
> acts exactly the same as TSVN: everything fine with local paths, issues with
> network drives. Sometimes, trying more and more, the checkout/commit
> succeeds also on network share, but it is a random occurrence.
>
> Any clue? As you can see in the suggested link, it seems that everyone who
> works on network drive has the same problem: something has been changed or
> broken in 1.9.X release about it? I didn’t find anything about it.
>
Bert and I were able to reproduce this issue with help from Daniele
and Marco. In short: Subversion 1.9.x doesn't work with working copies
stored on SMBv1 network shares (i.e. hosted on Windows XP/Windows
Server 2003 or Windows Server 2008 with SMBv2 disabled). It is not
related to background antivirus/indexers. So the bug affects many
users.

While r1701298 fix still makes sense to workaround background
antivirus/indexers it doesn't help to fix Access Denied errors on
SMBv1 network shares.

In nutshell problem is that SetFileInformationByHandle() API cannot be
called more than once if first call failed for any reason for SMBv1
shares. We retry SetFileInformationByHandle() call if destination
directory doesn't exist or if we rename over read-only file. It works
fine for local directories or SMBv2 shares, but doesn't work for SMBv1
network shares. SetFileInformationByHandle() returns
ERROR_ACCESS_DENIED without even sending request to SMB server.

We developed patch that converts all ERROR_ACCESS_DENIED errors from
SetFileInformationByHandle() to SVN_ERR_UNSUPPORTED_FEATURE and
fallbacks to normal close + rename() (see attached file), but I'm not
sure it's the best solution and going to investigate this problem
tomorrow.

--
Ivan Zhakov

Re: Access denied error on checkout-commit after updating to 1.9.X

[Ivan Zhakov <iv...@visualsvn.com>]

On 7 September 2015 at 19:45, Ivan Zhakov <iv...@visualsvn.com> wrote:
> [Moving to dev@s.a.o]
>
> On 4 September 2015 at 18:15, Daniele Pedroni
> <pe...@zapispa.it> wrote:
>> After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN
>> as well as command line throw the following error after trying to checkout
>> or commit a Working Directory on a network share:
>>
>> Commit failed (details follow):
>> Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to
>>
>> 'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base':
>>  Access is denied.
>>
>> (full discussion on TSVN mailing list here:
>> https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U )
>>
>> It seems to be a Subversion issue, not a TortoiseSVN one, since command line
>> acts exactly the same as TSVN: everything fine with local paths, issues with
>> network drives. Sometimes, trying more and more, the checkout/commit
>> succeeds also on network share, but it is a random occurrence.
>>
>> Any clue? As you can see in the suggested link, it seems that everyone who
>> works on network drive has the same problem: something has been changed or
>> broken in 1.9.X release about it? I didn’t find anything about it.
>>
> Bert and I were able to reproduce this issue with help from Daniele
> and Marco. In short: Subversion 1.9.x doesn't work with working copies
> stored on SMBv1 network shares (i.e. hosted on Windows XP/Windows
> Server 2003 or Windows Server 2008 with SMBv2 disabled). It is not
> related to background antivirus/indexers. So the bug affects many
> users.
>
> While r1701298 fix still makes sense to workaround background
> antivirus/indexers it doesn't help to fix Access Denied errors on
> SMBv1 network shares.
>
> In nutshell problem is that SetFileInformationByHandle() API cannot be
> called more than once if first call failed for any reason for SMBv1
> shares. We retry SetFileInformationByHandle() call if destination
> directory doesn't exist or if we rename over read-only file. It works
> fine for local directories or SMBv2 shares, but doesn't work for SMBv1
> network shares. SetFileInformationByHandle() returns
> ERROR_ACCESS_DENIED without even sending request to SMB server.
>
> We developed patch that converts all ERROR_ACCESS_DENIED errors from
> SetFileInformationByHandle() to SVN_ERR_UNSUPPORTED_FEATURE and
> fallbacks to normal close + rename() (see attached file), but I'm not
> sure it's the best solution and going to investigate this problem
> tomorrow.
>
I didn't find better solution and committed this patch in r1701736.

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com

Re: Access denied error on checkout-commit after updating to 1.9.X

[Ivan Zhakov <iv...@visualsvn.com>]

On 7 September 2015 at 19:45, Ivan Zhakov <iv...@visualsvn.com> wrote:
> [Moving to dev@s.a.o]
>
> On 4 September 2015 at 18:15, Daniele Pedroni
> <pe...@zapispa.it> wrote:
>> After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN
>> as well as command line throw the following error after trying to checkout
>> or commit a Working Directory on a network share:
>>
>> Commit failed (details follow):
>> Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to
>>
>> 'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base':
>>  Access is denied.
>>
>> (full discussion on TSVN mailing list here:
>> https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U )
>>
>> It seems to be a Subversion issue, not a TortoiseSVN one, since command line
>> acts exactly the same as TSVN: everything fine with local paths, issues with
>> network drives. Sometimes, trying more and more, the checkout/commit
>> succeeds also on network share, but it is a random occurrence.
>>
>> Any clue? As you can see in the suggested link, it seems that everyone who
>> works on network drive has the same problem: something has been changed or
>> broken in 1.9.X release about it? I didn’t find anything about it.
>>
> Bert and I were able to reproduce this issue with help from Daniele
> and Marco. In short: Subversion 1.9.x doesn't work with working copies
> stored on SMBv1 network shares (i.e. hosted on Windows XP/Windows
> Server 2003 or Windows Server 2008 with SMBv2 disabled). It is not
> related to background antivirus/indexers. So the bug affects many
> users.
>
> While r1701298 fix still makes sense to workaround background
> antivirus/indexers it doesn't help to fix Access Denied errors on
> SMBv1 network shares.
>
> In nutshell problem is that SetFileInformationByHandle() API cannot be
> called more than once if first call failed for any reason for SMBv1
> shares. We retry SetFileInformationByHandle() call if destination
> directory doesn't exist or if we rename over read-only file. It works
> fine for local directories or SMBv2 shares, but doesn't work for SMBv1
> network shares. SetFileInformationByHandle() returns
> ERROR_ACCESS_DENIED without even sending request to SMB server.
>
> We developed patch that converts all ERROR_ACCESS_DENIED errors from
> SetFileInformationByHandle() to SVN_ERR_UNSUPPORTED_FEATURE and
> fallbacks to normal close + rename() (see attached file), but I'm not
> sure it's the best solution and going to investigate this problem
> tomorrow.
>
I didn't find better solution and committed this patch in r1701736.

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com