[Moving to dev@s.a.o]
On 4 September 2015 at 18:15, Daniele Pedroni
<pedroni.dani...@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
Index: subversion/libsvn_subr/io.c
===================================================================
--- subversion/libsvn_subr/io.c (revision 1701642)
+++ subversion/libsvn_subr/io.c (working copy)
@@ -2065,12 +2065,18 @@
rename_size);
}
- WIN32_RETRY_LOOP(status,
- win32_set_file_information_by_handle(hFile,
- FileRenameInfo,
- rename_info,
- rename_size));
+ /* Windows Vista+ client accessing network share stored on Windows Server
+ 2003 returns ERROR_ACCESS_DENIED. The same happens when Vista+ client
+ access Windows Server 2008 with disabled SMBv2 protocol.
+ So return SVN_ERR_UNSUPPORTED_FEATURE in this case like we do when
+ SetFileInformationByHandle() is not available and let caller to
+ handle it. */
+ if (status == APR_FROM_OS_ERROR(ERROR_ACCESS_DENIED))
+ {
+ status = SVN_ERR_UNSUPPORTED_FEATURE;
+ }
+
if (status)
{
return svn_error_wrap_apr(status, _("Can't move '%s' to '%s'"),
