It’s been a frustrating few evenings (well 5 actually !) trying to sort out what was being done in Windows 7 x64 with the GetFileSecurity API and then what Explorer was showing me.
It turns out there are issues with how Dokan and Explorer treat each other, and then it’s all different when the same files are being accessed over a share to those same locations:
1) ACL’s not on NTFS drives
This caught me out, because the source format type, can be anything that windows recognises, then the API’s still have to work as if they have ACL (Because that is what Liquesce states as being supported). Now, this means that if the source type is anything other than a type that does not have ACL, then explorer (And other apps) do not know this.
Lets show you in some pictures, these are generated via the Liquesce Mount, but their underlying sources are different:
|FAT32 (Kylie)||NTFS (Test1)|
So the files(directories) without ACL, are shown with a padlock , and when going into the security tab of properties, you can see that “No permissions have been assigned etc."; and if you attempt to apply then it fails (Silly message box for every directory inside the parent).
The NTFS Test1 works as expected.
2) ACL access via a share
Explorer requests an additional ACL level when accessing files via a share = SACL_SECURITY_INFORMATION
This needs special permissions to retrieve and also access to certain levels of the OS API’s. Even running as a service and setting a manifest file with the permissions set to “highestAvailable”, the code that actually calls the GetFileSecurity API does not get the expected result.
Returning access denied to explorer just stops it going any further, so that is not helpful. The (current) answer is to go and implement the workaround mentioned in http://code.google.com/p/dokan/issues/detail?id=209
So what’s next? Well Testing on all the supported platforms, and some additional text in the testing procedure