Why System.IO.Directory.Delete(string,bool) only markes a folder as deleted, when a asp.net site impersonates a user

Question

I have a strange behavior in my asp.net 4.0 Application, since i have updated to Windows10 (i think it came with 10).

I have an application which uses BasicAuthentication in IIS - in my Login.aspx i'm manually verifying the user and the password against a defined AD-Domain. If the credentials are valid, i store a simple object with some userdata in the session & redirect to my the mainpage.

So far so good - With the application the user is able to delete files & directories. These operations are always performed under a impersonation context of the current user.

Entering "Impersonation Context": (main parts only)

[PermissionSetAttribute(SecurityAction.Demand, Name = "FullTrust")]
public virtual void Enter(LogonType logonType = LogonType.LOGON32_LOGON_INTERACTIVE, LogonProvider provider = LogonProvider.LOGON32_PROVIDER_DEFAULT)
{       
    token = IntPtr.Zero;

    //Create the token
    bool logonSuccessfull = GetToken(this.username, this.password, this.domain, ref token, logonType, provider);

    WindowsIdentity identity;
    identity = new WindowsIdentity(token);
    impContext = identity.Impersonate();                               
}

if the user deletes a Directory:

Public void Delete(string directory)
{
    //1. Entering impersonation context before (context.Enter();)

    //2. Delete the file (executing this basic .net method):
      System.IO.Directory.Delete(directory, true);

    //3. Leaving the impersonation context after (context.Leave() -> .Undo();)
}

After that operation i can still see the directory as administrator in the explorer (which was closed before). But if i want to open the folder, i get a access denied message. I'm also not able to watch the permissions of the directory or become the owner of this 'ghost-folder'. A quick filesystem check didn't helped too.

But: If the applicationpool ends - the folders are gone...

The Applicationpool is a Classic .net 4.0 Pool with Network-Identity (changeing this settings did not solved the problem at this point)

Has anyone an idea why they do not get deleted immediately? & how can i force it?

Answer 1

At least i found the Issue. The problem was, that i have invoked the Impersonation twice or more in some cases. So i was already in an impersonation state and called the impersonation code again... This was not a problem before Windows 10 but after as it seems..