[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Mon, 7 Sep 2015 19:45:04 +0300

[Moving to dev_at_s.a.o]

On 4 September 2015 at 18:15, Daniele Pedroni
<pedroni.daniele_at_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

Received on 2015-09-07 18:45:40 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.