Delay in Temporary File Deletion and Residual File Handles in Azure Files

Question

Body: Hello, I'm using Azure Files in an SAP on Azure environment.

Currently, I'm facing the following issue:

• SAP outputs temporary files to Azure Files.
• Although the files are deleted using ABAP's DELETE command, file handles remain temporarily.
• The files are only fully deleted after several minutes to tens of minutes (apparently released automatically over time).

Based on my investigation, the following technical factors may be contributing to this behavior:

SMB Protocol – Delayed File Close Azure Files uses caching and delayed close mechanisms for performance. Even after a delete command, the file may appear "open" due to Azure-side caching.

Replication Lag in Azure Files File deletion is not reflected immediately due to inherent latency in cloud-based replication.

ABAP DELETE Command May Result in "Delete Pending" The file is marked as "delete pending" at the SMB layer and only removed after the handle is fully released.

This behavior can cause errors if the application tries to rename or recreate the file immediately after deletion.

---

Questions:

• Is this behavior expected as part of Azure Files' design?

---

Additional Info: As a workaround, we are currently inserting a short wait (a few seconds) after deletion, which helps mitigate the issue. However, we would like to understand whether a fundamental redesign is necessary, and would appreciate insights from the community.Body:

Hello, I'm using Azure Files in an SAP on Azure environment.

Currently, I'm facing the following issue:

• SAP outputs temporary files to Azure Files.
• Although the files are deleted using ABAP's DELETE command, file handles remain temporarily.
• The files are only fully deleted after several minutes to tens of minutes (apparently released automatically over time).

Based on my investigation, the following technical factors may be contributing to this behavior:

SMB Protocol – Delayed File Close
Azure Files uses caching and delayed close mechanisms for performance. Even after a delete command, the file may appear "open" due to Azure-side caching.

Replication Lag in Azure Files
File deletion is not reflected immediately due to inherent latency in cloud-based replication.

ABAP DELETE Command May Result in "Delete Pending"
The file is marked as "delete pending" at the SMB layer and only removed after the handle is fully released.

This behavior can cause errors if the application tries to rename or recreate the file immediately after deletion.

---

Questions:

• Is this behavior expected as part of Azure Files' design?

---

Additional Info:
As a workaround, we are currently inserting a short wait (a few seconds) after deletion, which helps mitigate the issue. However, we would like to understand whether a fundamental redesign is necessary, and would appreciate insights from the community.

Answer 1

Hello 勝也 佐々木

Thank you for your question!

The documentation on Azure file Azure Files SMB overview and SMB protocol specifications https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/ confirm that file deletions can be deferred until handles are closed, especially in scenarios with caching or oplocks enabled.

To clarify on whether the observed behavior of delayed file deletion and lingering handles in Azure Files, particularly with SAP applications and SMB, is expected as part of Azure Files' design.

Is this behavior expected as part of Azure Files' design?

Yes, to a certain extent, this behavior (delayed handle release and a "delete pending" state) is an expected characteristic of distributed file systems, including Azure Files, especially when accessed over the SMB protocol and interacting with caching mechanisms.

Workaround:

• Increase the wait time to 10-15 seconds and monitor if the delay ever exceeds this. If it does, investigate specific instances (e.g., log the file name and timestamp) to identify patterns.
• Use a tool like Process Explorer on the SAP server to check for open file handles after the DELETE command.
• Check SMB client settings on the SAP server (e.g., registry keys like HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters) for caching or oplock settings. Consult Microsoft’s SMB tuning guide (SMB performance tuning) for adjustments.
• Review SAP documentation or logs to ensure the DELETE command is not part of a larger transaction keeping handles open.

Note: If optimization doesn’t suffice, test a hybrid approach: Use a local disk for temporary files during SAP processing, then move them to Azure Files after deletion. This avoids SMB-related delays for temporary operations.

Hope the above answer helps! Please let us know do you have any further queries.

---

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.