DeleteFile doesn't return an error even when the server replies with "STATUS_NETWORK_NAME_DELETED" error

Applies to: Windows 8.1 EnterpriseWindows 8.1 ProWindows Server 2012 R2 Datacenter


On a Windows 8.1 or Windows Server 2012 R2 client, the Win32 DeleteFile function does not return an error when the server replies to a Close request with a "STATUS_NETWORK_NAME_DELETED" Server Message Block 2 (SMB2) error. Therefore, the client application is unaware that the file delete request actually failed. After this occurs, the file may remain on the server until it detects that no persistent reconnect has occurred. The server then deletes the file.

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 may occur if the server encounters an error while it's processing the client DeleteFile request. For example, this may occur when there's a problem accessing the file system, or if the network connection between the client and server is lost. In order to trigger this problem, this error must occur within a very brief timing window, during the DeleteFile request.

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.)


Because the server eventually deletes the file when it fails to detect a persistent reconnect from the client, no user action is required to delete the file. The third-party SMB3 server in question implemented a persistent reconnect time-out of 60 seconds. Other SMB3 server implementations may use a different value. The persistent reconnect time-out differs from the ResiliencyTimeout setting, which defaults to 120 seconds.

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. 

More Information

For more information about the SMB3 protocol dialect, persistent reconnect, and the requirements for handling a connection loss, see section "Handling Loss of a Connection" in the SMB2 protocol specification: