However, if the client tries to remove the directory from which the file was deleted while the server is waiting for a persistent reconnect to occur (typically 60 seconds, although the time-out period may vary, depending on SMB3 product implementation), the request fails with a "STATUS_DIRECTORY_NOT_EMPTY" error.
Note A network trace must be captured in order to detect that the server replied to the client's SMB2 Close request with a "STATUS_NETWORK_NAME_DELETED" (0xC00000C9) error.
This problem was discovered during stress testing of transparent failover, where the file system is brought down and back up while file operations are in progress. After the error, the server may continue to persist the open file handle and wait for a persistent reconnect to occur. Because the client application was not notified of an error, no persistent reconnect occurs. Therefore, the file remains until the server eventually deletes it when the persistent reconnect time-out period expires. (This last behavior occurs because the file handle is in a "delete-on-close" state on the server.)
There is no resolution for this DeleteFile function problem. Microsoft has evaluated the underlying cause and has determined that fixing the error handling during this small timing window could cause unexpected problems with other applications that are deployed in the Windows ecosystem. Therefore, no hotfix is being released for this issue.
Artikel-id: 3044432 – senaste granskning 12 mars 2015 – revision: 1