Kyle H

As a workaround for this, you might spawn a new thread and run DokanMain from that thread, using a mailslot or named pipe to communicate with your main thread.

The problem is that only administrators (or elevated users) can access the drive after it's been mounted. The default security descriptor assigned to the filesystem does not grant standard users...

I can imagine the support requests from this: "It worked until I rebooted, but I didn't change anything." There would need to be instrumentation to explain the current driver version...

I'm pretty sure the account you use to run Dokan needs to have SeImpersonatePrivilege, and then you need to spawn a thread and have it call an Impersonate syscall at...

I haven't had a chance to evaluate these thoughts as yet. I may not have time until Tuesday November 26. Please wait until then to make a decision. -Kyle H...

As nice as spdlog is, I think I prefer the idea of being able to provide a struct of logging callback procedures. There's going to be something different that needs...

This causes a bad interaction with my suggestion on https://github.com/dokan-dev/dokan-dotnet/issues/139 , namely that said suggestion won't work because of it.

@amarcionek, the SubjectSecurityContext is kind of available to the user code, via the function DokanOpenRequestorToken(). (In Dokan.Net, it's available via DokanFileInfo.GetRequestor().) I'm not sure how the kernel could obtain the...

@amarcionek Okay, I've got a better idea of what's going on in kernel-land now. The same mechanism that makes the SubjectSecurityContext available to one IOCTL would make it available to...

File system developers don't need to care what's in a security descriptor if and only if they're not operating outside of the preconceived notions that Microsoft has written its design...