On 7 September 2015 at 19:45, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> [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.
>
I didn't find better solution and committed this patch in r1701736.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2015-09-08 09:44:47 CEST