the problem is to identify the source of the access error - it might be missing permission of the asp.net user to delete the file or the file might be occupied by a different process - e.g. ASP.Net scanning for changed files which require a recompile (unfortunately, portals subtree is not excluded from this scan, due to skins and containers as well as module files may reside inside.

One thing of note:  this happened exactly when I upgraded to 5.2.1, which included changes to the web.config to add the following providers -

    <moduleCaching defaultProvider="FileModuleCachingProvider">
      <providers>
        <clear />
        <add name="FileModuleCachingProvider" type="DotNetNuke.Services.ModuleCache.FileProvider, DotNetNuke.Provider.ModuleCaching.FileProvider" providerPath="~\Providers\ModuleCachingProviders\FileModuleCachingProvider\" />
        <add name="MemoryModuleCachingProvider" type="DotNetNuke.Services.ModuleCache.MemoryProvider, DotNetNuke.Provider.ModuleCaching.MemoryProvider" providerPath="~\Providers\ModuleCachingProviders\MemoryModuleCachingProvider\" />
      </providers>
    </moduleCaching>
    <outputCaching defaultProvider="FileOutputCachingProvider">
      <providers>
        <clear />
      </providers>
    </outputCaching>