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