You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Winbow, Alexander G" <al...@intel.com> on 2015/10/22 21:37:04 UTC
Access Denied error on checkout to SMB share with 1.9.2, but not 1.8
When trying to do a basic checkout, writing to a directory residing on a SMB network share (netapp), I get intermittent errors "Can't stat <pathname> Access is denied". This happens with SVN 1.9.2 (or TortoiseSVN 1.9.2), but not with SVN 1.18.14.
This seems awfully similar to the issue discussed by Ivan Zhakov in:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201509.mbox/%3CCABw-3YdBU6hQkYu73+HzVxhohfVWUuR8OgdhBiJmHhfqBqBdzA@mail.gmail.com%3E
... and the changeset r1702370 (which references r1701064, r1701206, r1701298, r1701736), however it is happening in SVN 1.9.2 which seems to have been released after that patch was committed.
There may be some differences: this is probably an SMBv2 mount (the SVN client is running on Win7). It probably is related to an antivirus scanner in some manner, since this error occurs only on files that are known to be being scanned on the SMB-server side. (The server team ask "is it possible that your file gets modified during the activity you are doing? .... it's been tagged as virus because of the weird behavior of file getting lost during scanning". Does any of that make sense, from the perspective of what the svn client code is doing at a low level?)
The fact that this occurs only on SVN 1.9.2 and not on 1.8.14 strongly suggest there is an SVN component to this behavior, and perhaps it's the SetFileInformationByHandle() API referenced in the bug discussed above.
Thanks,
-Alex
RE: Access Denied error on checkout to SMB share with 1.9.2, but
not 1.8
Posted by "Winbow, Alexander G" <al...@intel.com>.
Hi, Ivan,
Thanks for responding. Here is the exact output of "svn co" using 1.9.2, with the directory and filenames appropriately elided.
----------------------------------------------------------------------------------------------------------------------------------------------------
[... a hundred files or so ...]
A dir6\dir7\fileN-1
A dir6\dir7\fileN <------ notice this is fileN, which appears below in error message
A dir6\dir7\fileN+1
A dir6\dir7\fileN+2
A dir6\dir7\fileN+3
A dir6\dir7\fileN+4
A dir6\dir7\fileN+5
A dir6\dir7\fileN+6
A dir6\dir7\fileN+7
svn: E155009: Failed to run the WC DB work queue associated with 'I:\dir1\dir2\dir3\dir4\dir5\dir6\dir7', work item 137 (file-install dir7/fileN 1 0 1 1)
svn: E720005: Can't stat 'I:\dir1\dir2\dir3\dir4\dir5\dir6\dir7\fileN': Access is denied.
----------------------------------------------------------------------------------------------------------------------------------------------------
Thanks,
-Alex
-----Original Message-----
From: Ivan Zhakov [mailto:ivan@visualsvn.com]
Sent: Friday, October 23, 2015 12:24 AM
To: Winbow, Alexander G
Cc: users@subversion.apache.org
Subject: Re: Access Denied error on checkout to SMB share with 1.9.2, but not 1.8
On 22 October 2015 at 22:37, Winbow, Alexander G <al...@intel.com> wrote:
> When trying to do a basic checkout, writing to a directory residing on a SMB network share (netapp), I get intermittent errors "Can't stat <pathname> Access is denied". This happens with SVN 1.9.2 (or TortoiseSVN 1.9.2), but not with SVN 1.18.14.
>
Could you please provide exact error message that you get? With filename and other stuff. This would help to find which operation actually failing.
--
Ivan Zhakov
Re: Access Denied error on checkout to SMB share with 1.9.2, but not 1.8
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 22 October 2015 at 22:37, Winbow, Alexander G
<al...@intel.com> wrote:
> When trying to do a basic checkout, writing to a directory residing on a SMB network share (netapp), I get intermittent errors "Can't stat <pathname> Access is denied". This happens with SVN 1.9.2 (or TortoiseSVN 1.9.2), but not with SVN 1.18.14.
>
Could you please provide exact error message that you get? With
filename and other stuff. This would help to find which operation
actually failing.
--
Ivan Zhakov