AnkhSVN breaks ASP.NET sharing permissions with SVN 1.7

Question

The Background (skip to the bottom if you want the question)

Recently I upgraded an SVN repository (hosted on assembla) to SVN 1.7. After doing so, we started to intermittently encounter lots of File Access Denied errors on the ASP.NET site pages that sit in the local working copy of the repository.

Some folders also started to get weird file permissions (they became marked read-only) and user sharing got removed from them. These problems would only start occurring after an update/commit cycle, via AnkhSVN's Visual Studio plugin, but not all the time; it seemed highly temperamental.

The only temp-fix we've found so far is to commit any outstanding changes, delete the local copy and re-checkout a full working copy (with TortoiseSVN). However, that is not a viable fix, and it is seriously impacting on productivity.

This site is an Azure based ASP.NET WebWorkerRole. It has never given problems before the upgrade to SVN 1.7. I tried fiddling with the internal IIS permissions to get around the problem, however, no dice.

My Environment

• Visual Studio 2010 Ultimate 10.0.40219.1 SP1
• AnkhSVN 2.3.10509 (latest version, supports SVN 1.7.1)
• TortoiseSVN 1.7.1, Build 22161 - 64 Bit
• Running in Debug Mode via the Azure emulator environment

The Question

Is it possible for SVN 1.7 or any of the tools in my environment to break file permissions so that the files become unusable in an ASP.NET site? and more importantly, how do I fix this?

---

The exact file permission error dumped out is this:

Access to the path '//file//' is denied.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.UnauthorizedAccessException: Access to the path '//file//' is denied.

ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6 and IIS 7, and the configured application pool identity on IIS 7.5) that is used if the application is not impersonating. If the application is impersonating via , the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.

To grant ASP.NET access to a file, right-click the file in Explorer, choose "Properties" and select the Security tab. Click "Add" to add the appropriate user or group. Highlight the ASP.NET account, and check the boxes for the desired access.

But a clean working copy will not generate this error. Comparing the permissions of the two, it seems the working copies that are not bugged are shared (with IUSR and the local account), whereas the broken ones have zero sharing, yet the sharing is never changed by the user.

Answer 1

I solved this by accessing the security settings for the website folder and and clicking Advanced and then Change Permissions for the IIS_IUSRS user. I checked the "Replace all child object permissions with inheritable permissions from this object" and clicked apply.

Before that, I had given the IIS user full permissions to the hidden tmp folder in the root of the checkout, but I don't know if this helps with anything.

I'm not sure if this is a permanent fix, but in case it is not, you can at least use it to reapply permissions for all the files in a single operation.

Answer 2

When subversion updates a file it first creates a temporary version in .svn/tmp/. It then moves the file into the right location. (This to avoid corruptions)

In 1.6 it did this for every directory by itself, but in 1.7 there is just a .svn in the top level directory of your working copy.

If somehow the filesystem permissions of this .svn directory are restricted, it is possible that the restrictions are copied with the file when it is moved in place. (Subversion doesn't change the permissions itself on Windows)

Answer 3

Much information is located in .svn folders inside directory where project was checked out. So in my opinion better use SVN separately from advanced integration tools. Also this deals with solving problem like this.

Answer 4

I found this exact same issue happened when I did a 'Revert' using:

• Tortoise Svn 1.6.16
• AnkhSVN 2.3.11269.1348.
• Visual Studio 2010 Professional
• Windows 7 - 64 bit.

I was completely puzzled the first time I encountered the permissions error and started off by thinking it was my code. After a while of fiddling about I ended up deleting the whole project and re-downloading from Subversion which fixed the issue.

When this problem happened again I looked more closely at the reverted file, and I found the permissions on the reverted files do not match the permissions of the other files. Specifically 'Users' permissions, for the machine that Visual Studio is running on, is missing altogether.

So I just added it in by:

• Right clicking on the problem file. This caused the file properties window to appear.
• Then clicked on 'Edit...'. The permission window appears.
• Then clicked on Add and the 'Select Users, Computers, Service Accounts, or Groups window appears.
• Click on the Object Types button and check all the boxes.
• Click on the Locations button and make sure your machine name is selected.
• Type in 'users' then click the 'check names' button.
• Click OK on all the windows to close them.

Your website should now run without the permissions error.