This is an Inter-OP issue with a third party FS encryptor product which
aparantly seems to be violating some rules.
When this software is installed the File Properties ->Advanced -> Encrypt
Contents check box gets greyed out and one cannot use EFS. However, going
through the local policy settings makes us believe that they are not
creating any such policy, but instead their filter driver is removing the
encryption bit (and maybe something more).
Our product wants that a particular directory remain unencrypted through EFS
or other wise. So we were calling the EncryptionDisable API to achieve
this.
With the third party product installed, this API starts failing, reason :
the desktop.ini file created by this API is being encrypted by this product
and this probably confuses EFS.
The error returned is generic (end of file reached). So we cannot even do
handling on it.
The problem is, if we remove the call to this API, and some where down the
line the user uninstalls the third party encryptor, then our folder will be
available of encryption and this will break functionality.
I have tried this:
Use IoCreateFileSpecifyDeviceHint and created the desktop.ini file
(bypassing all filters) with the right settings, but I am not sure, whether
the original API does something more which I am not doing. Things seem to
work, but I am unhappy about bending the rules here…
Earlier, to avoid our files (in this specific folder) to be encrypted by
such third party products we had to use teh same api instead of
ZwCreateFile.
BTW, we are at volume level, and not a file system filter.
Any suggestions on how to better bypass this issue? No we cannot contact
this third party vendor.
- amitr0