We have a software utility that we wrote and continue to maintain that performs deletion of files as one part of its functionality. The utility needs to be able to delete any file or directory, regardless of the actual NTFS permissions, provided that
the file / directory is not currently held open such that a call to CreateFileW() cannot open it exclusively for DELETE access. To facilitate this, our utility enables the LSA privileges SE_BACKUP_NAME and SE_RESTORE_NAME and then calls CreateFileW()
requesting DELETE access, no sharing, OPEN_EXISTING disposition, and specifying the flags FILE_FLAG_BACKUP_SEMANTICS and FILE_FLAG_DELETE_ON_CLOSE. This ensures that backup semantics are used, thus allowing our enabled LSA privileges to be used to bypass
NTFS permissions. It should also be noticed that the file / directory name that is passed in to CreateFileW() is always an absolute path in either drive letter format or UNC format, and it always has the appropriate prefix applied [e.g. "\\?\"
or "\\?\UNC\"] to permit the use of long names up to 32,000 Unicode wide characters in length.
This has been working successfully for many years, and even roaming user profiles can be deleted without first having to modify the NTFS permissions to make deletion of the files and directories possible.
Recently, it came to our attention that in certain customer environments where both Shadow Copies of Shared Folders is enabled and FSRM Directory Quotas are in use, that the deletion of files using this methodology is resulting in the quota utilization not
being updated by the quota mini-filter driver. However, deleting the file using the DEL command in CMD.EXE or performing a SHIFT-DELETE keystroke in the Windows Explorer [and acknowledging the permanent deletion prompt] results in deletion of the specified
file with correct updating of the quota utilization. This behavior, however, is only observed on Windows Server 2008 R2 [Enterprise] with patches applied through 4/1/2013. Identical testing on Windows Server 2012 [Enterprise] with patches applied
through 4/4/2013 does not result in manifestation of this problem. If the Shadow Copies of Shared Folders is disabled and all previous shadow copies for the volume in question are thus deleted, then FSRM Quota utilization values are always updated correctly
regardless of how the file is deleted.
I have performed extensive Google searching of the Internet and direct searching of Microsoft's Technical Support, TechNet and DeveloperNet web sites looking for information about this problem, and have not found anything at all except some old references to a problem on Windows Server 2003 R2 that had very similar symptoms.
I am interested in finding out if Microsoft or anybody else had encountered this problem, or if they can reproduce it. Also, if there is a hot fix or some other patch available for Windows Server 2008 R2 that fixes this problem, I'd like to know how to obtain it as there doesn't seem to be a KB article in existence that refers to this problem or any such hot fix or patch.