The process cannot access the file 'C:\git\Umbraco-CMS\src\Umbraco.Web.UI\App_Data\TEMP\NuCache\NuCache.Content.db'

[darrenferguson]

I've done a quick search over the issue tracker for: NuCache.Content.db and can see a dozen or so issues around the exception - "The process cannot access the file 'C:\git\Umbraco-CMS\src\Umbraco.Web.UI\App_Data\TEMP\NuCache\NuCache.Content.db'"

Which I am facing locally from time to time in Umbraco 8.17.1 but frequently in Azure Webapps when deploying.

I can see from the issue history that this is hard to reproduce, and although it has been worked on a few times, it does occur quite often still (from personal observations).

It is fairly straightforward to identify where the issue occurs in code: Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService - MainDomRegister method.

_localContentDb = BTree.GetTree(localContentDbPath, _localContentDbExists, _contentDataSerializer);
_localMediaDb = BTree.GetTree(localMediaDbPath, _localMediaDbExists, _contentDataSerializer);

As we are in managed code - it is going to be pretty much impossible to observe what is locking the files.

I can see that the issues to address this to date have been around ensuring that this application is the only one running - to ensure that it is the only one trying to access the files (previous attempts have included disabling overlapped recycling etc).

What I can't see (and I may be wrong) is any assessment of the possibility that a non .NET process (virus checker, etc) may be interfering with the file.

It is quite easy to reproduce the problem locally. I've just downloaded a small piece of software called Filelocker (https://www.jensscheffler.de/filelocker). I stop IIS, take a lock on NuCache.Content.db, start Umbraco - and... it doesn't start.

I wanted to open a discussion here - because I think there are a couple of workarounds.

Using a custom composer I can replace the IPublishedSnapshotService

The extension point isn't ideal, as to get into the MainDom method (which is private) I pretty much have to duplicate the whole original class.

In my version - I then try and wait for a lock on NuCache.Content.db and if it fails after "x" attempts, I just use a new filename.

The point of the discussion here is:

• Can we improve the extensibility somehow, so I can manage what happens when the NuCache.Content.db - can't be locked - e.g. provide just an implementation of a method to acquire the NuCache file.
• Can we add the retry functionality to the core?

I'm happy to do some leg work to provide the PR, I'd just like some HQ "pre-approval" before I plough ahead.

[NikRimington]

Hi Darren,

Thank you for raising this discussion as I'm still getting this issue frequently on a variety of v8 sites (all of which I believe are on v8.15 or newer).

Your idea of using a different name is interesting, what could also be of use is if the areas within Umbraco that directly access the NuCache file itself could raise a flag to indicate is the current site is what is locking the file or not. That could help speed up the decision to use a new file or try waiting to see if the lock releases.

We have a site that has 50k+ cache entries and it takes an age for it to start. While it is starting it is locking the nucache file, but other things within the site try to access it. This slow start up is (as far as I can tell) SQL data reading and NuCache generation related so I thought it might be helpful information.