A file or directory is deleted when a deletion request is pending and the last user reference to the file is released (that is, the last IRP_MJ_CLEANUP is sent to the file system).
Deletion is requested on a file or directory in one of two ways:
When the file/directory is opened, FILE_DELETE_ON_CLOSE is set. The exact semantics of this are complicated because the file systems explicitly check for this, explicitly add DELETE access to the access required (even if not requested originally) and must deal with issues regarding directories (a directory must be empty before it can be marked delete pending).
For an already opened file/directory, the IRP_MJ_SET_INFORMATION, specifying FileDispositionInformation and then providing the FILE_DISPOSITION_INFORMATION structure indicating TRUE for the DeleteFile field.
In these cases the file is now scheduled for deletion, but that can be changed by a subsequent call to modify the file disposition (indicating FALSE for the DeleteFile field.)
Note that the EXACT semantics are file system specific. Do not be surprised if you see some differences in the seven general purpose file systems currently available from Microsoft. For example, CDFS and UDFS currently do not allow you to delete files (note the term "currently" - were Microsoft to provide a read/write UDF file system, then we suspect these semantics would change.) NFS semantics are very different than CIFS semantics for deletion. Similarly, the semantics of the Netware File System are also unclear.