I want to manually delete entries in the DNN_Folders table that point to non-existent filestore and am looking for a reality-check before I do so. Here is why I want to do it:
I had an issue that on SOME portals, any attempt to access HTML Editor config, or to use the Browse Server functionality via inserting link in the HTML Editor results in a non-responsive thread and every portal stops responding. I switched from the old CK Editor Provider to the new DNN Connect versions and this changed the character of the issue - instead of w3wp.exe spinning forever it is now SQL Server that runs constantly at 25% CPU.
I ran an SQL Trace and discovered the issue is caused by thousand upon thousand of calls to DNN_GetFolderPermissionsByPortalAndPath, and the parameter for each include a path that does not exist in the portal in question (e.g. exec sp_executesql N';Exec dbo.DNN_GetFolderPermissionsByPortalAndPath @0, @1',N'@0 int,@1 nvarchar(4000)',@0=47,@1=N'Users/116/48/37748/') - and portals/47/users/116 does NOT exist on disc
I think the root cause might be that a couple of years ago I suffered a spam registration attack and ended up with an apparent user base of over a quarter of a million users. After closing the hole that was allowing the spam bots in, I manually deleted most of the user accounts from the DNN_Users table (yes, yes, I know I shouldn't have done that now!). I subsequently deleted all the underlying empty folders in the portals/users folders for the affected portals.
So that brings us up to date, and now I see the problem I reported above only in those portals where the spam attacks occurred, and only tracing non-existent folders - this leads me to believe the iterative calls are being driven by entries in the DNN_Folders table - where those non-existent folders DO still exist.
My suspicion is that if I write a procedure to scan the DNN Folders table, and delete all entries where the nominated folders does NOT exist in the underlying filestore, my latest problem MAY be fixed. I am aware the DNN_Folders table contains a heirarchy (ie each entry has a parentid) and I shall have to be careful to delete from the bottom up, as it were.
Obviously I will test this on a restored backup first, but if anyone out there has any further insights or advice I would be most grateful to receive it.