Microsoft’s “File Security and Access Rights” documentation states that it:
“Grants the right to delete a directory and all the files it contains (its children), even if the files are read-only.”
http://msdn.microsoft.com/en-us/library/windows/desktop/aa822867(v=vs.85).aspx
It is also mentioned here:
http://support.microsoft.com/kb/238018
Do you have to get a handle to the root directory with the FILE_DELETE_CHILD access right, and can then get handles to its children with the DELETE standard access right by performing a relative open (and it will succeed even if they are read-only)?
Or does it give unlink semantics to the directory, where it can be deleted even if it contains other files?
Or does it do something else?
Regards,
Nick
Windows has no unlink semantic. All the file systems are implemented such that a non-empty directory cannot be deleted.
You don’t pass FILE_DELETE_CHILD as a flag in your create, as it sounds like you’re asking. If an ACE on the ACL of a given directory specifies you as a trustee, and that ACE grants FILE_DELETE_CHILD access, then you can specify DELETE access when opening children of that directory and delete them, whether they’re read-only or not.
–
Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.
Thanks for the reply.
What I am trying to achieve is deletion without having to unset the read-only flag on the file.
When holding SE_BACKUP_NAME and SE_RESTORE_NAME and passing FILE_OPEN_FOR_BACKUP_INTENT, I still have to clear the read-only bit.
Why is this? Surely FILE_DELETE_CHILD should be implicit with SE_RESTORE_NAME so I shouldn’t have to…
It would also be nice if FILE_OPEN_FOR_BACKUP_INTENT would make the file system ignore the read only bit completely, which is a vestige from the DOS days. Alas, it does not.
Thanks,
Nick
Holding SE_RESTORE_NAME grants you DELETE access to the file you open, so FILE_DELETE_CHILD on the parent would be irrelevant. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx for a description of the access rights that SE_RESTORE_NAME gives you.
After looking at some documentation and the implementation of SetDisposition and Create in NTFS I think the reference to the file being “read-only” is misleading in this context (and I wasn’t much help with my earlier reply). In this instance “read-only” is referring only to the access granted by the ACL on the file you’re trying to delete; the DOS bits aren’t considered. So, FILE_DELETE_CHILD allows you to delete contents of a directory even if the ACLs on those contents don’t grant you any kind of modify/delete access. However, the DOS read-only bit is considered separately from the ACL mechanism when deleting. A file with DOS read-only always denies delete, whether you’re doing it via SetDisposition or create with DELETE_ON_CLOSE.
Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.
Ah, thank you for clearing that up. It makes sense now. 
No chance of a design change at any point in the future to make the DOS R/O bit acquiesce either to FILE_OPEN_FOR_BACKUP_INTENT alone or it passed with the SE_RESTORE_NAME privilege also held?
I wouldn’t hold my breath.
Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.
http://us.generation-nt.com/answer/dos-o-attribute-backup-privileges-help-31030342.html#r
A quick search shows it has been brought up before actually. Cygwin would certainly like you for it!
Thank you so very much for clearing up my confusion.
It would be helpful if a documentation niggle could be filed to see if the wording could be cleared up for FILE_DELETE_CHILD. I certainly misinterpreted it as meaning the DOS R/O bit, others might too.
Regards,
Nick