Shadow copies fails to gracefully handle deleted folders between publishes

[kiwiant]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Shadow copies (enableShadowCopy) are great but if removing a folder in the published site this causes the site not to load with the following in the Windows event log:

EventID: 1007
Source:  IIS AspNetCore Module V2 
Message: Application '/LM/W3SVC/2/ROOT' with physical root '_(path to site)_' failed to load coreclr. Exception message:
Unexpected exception: directory_iterator::directory_iterator: The system cannot find the path specified.: "_(path to site)_\wwwroot\.well-known"

Expected Behavior

I like many others would expect this scenario to be handled gracefully either cleaning up the shadow copy or ignoring the deleted folders in the published site.

Steps To Reproduce

1. Create a new ASP.NET Core App (.NET 8) in Visual Studio with a dummy folder in wwwroot.
2. Enable shadow copies in the web.Release.config:

<handlerSettings>
    <handlerSetting name="enableShadowCopy" value="true" />
    <handlerSetting name="shadowCopyDirectory" value="..\..\ShadowCopy\_(site name)_" />
</handlerSettings>

3. Publish the site to IIS on Windows Server 2022 with the ASP.NET Core 8 Hosting bundle.
4. Validate the site works correctly.
5. Remove the dummy folder from the wwwroot folder and republish the site.
6. Confirm the site doesn't load and the event log contains the message as described above.

Exceptions (if any)

Unexpected exception: directory_iterator::directory_iterator: The system cannot find the path specified.: "(path to site)\wwwroot.well-known"

.NET Version

8.0.0

Anything else?

IIS runtime support (ASP.NET Core Module v2): 18.0.23305.0
Issue also present in .NET 7.x.

[amcasey]

Is this #48233?

[kiwiant]

Is this #48233?

Thanks, and yes indeed, I must have been using different keywords when searching.

Pretty undocumented cleanShadowCopyDirectory is right. In my test it appears to recreate everything in the shadow copy folder so might need some performance testing around this if used in production.

Regardless of this setting I believe there's still a bug as this is unexpected behaviour. Happy to this marked as duplicate of #48233 although it's fallen on deaf ears.

[amcasey]

Yeah, I'm sorry that we can't always turn around fixes as quickly as we like. I think the best way forward is to mark this as a duplicate and upvote the original to make it easier to see the level of customer impact in a single issue.