Subfolders for extentions skipped to delete.

[SergeyDryomin]

Description of bug

Subfolders for extentions skipped to delete.

Steps to reproduce

List the steps to reproduce the behavior:

1. Login to DNN as host.
2. Install extention with subfolders (Try DnnBootster)
3. Open folder where skin installed ("C:\dnndev.me\Portals_default\Skins\DnnBootster")
4. Go to setting> extensions and select themes from the list.
5. Delete DnnBootster with checked "Delete Files"

Current result

Subfolders into DnnBootster folder ("C:\dnndev.me\Portals_default\Skins\DnnBootster") are not deleted. It also blocks to delete Theme from Extensions

Expected result

Subfolders into DnnBootster folder ("C:\dnndev.me\Portals_default\Skins\DnnBootster") should be deleted . Theme should be deleted in Themes after page refreshed

Video to reproduce

https://drive.google.com/file/d/1JNjE7kGKL-GGEVqaq1j2qC649lqWRDlD/view?usp=sharing

Affected version

• 10.0.0 nightly build
• 9.4.1 nightly build
• 9.4.0 release candidate
• 9.3.2 latest supported release

Affected browser

• Chrome
• Firefox
• Safari
• Internet Explorer
• Edge

[mitchelsellers]

This is partially b y design, if the manifest doesn't list a file it isn't actually going to be deleted as part of the process.

[SergeyDryomin]

This is partially b y design, if the manifest doesn't list a file it isn't actually going to be deleted as part of the process.

these files are in manifest. I've already created a fix - creating PR now. The problem - subfolders in manifest contain other slash, so File.Exists returns false

[valadas]

I can reproduce this issue in 9.4.0 RC.

When files are zipped in a manifest like Resources.zip, then the installer generates a Resources.zip.manifest file to keep track of what was in the original zip in order to be able to later remove those files when uninstalling. So this issue appears to be with that list of files. The uninstaller probably splits the parts on \ to recursivelly delete the file, then the subsubfolder then the subfolder then the folder, etc. And my guess is that those parts keep the \ in for the folder name. Anyway I tested the proposed PR it fixes the issue and does not look to me like any breaking change. But waiting on @SergeyDryomin to see if we can get this resubmitted targeting release/9.4.x instead.

[valadas]

Closing since PR got merged