Runtime: [3.1] [Linux] Writing a file that takes you over the storage quota in Azure file storage silently fails

[flin-8]

Description

When using File.Copy() in Linux to write a file that takes you over the storage quota in Azure file storage, the write silently fails while leaving behind a truncated file.

• Repeating this on Windows throws an IOException (as expected) and doesn't leave a file behind. Stack trace:

System.IO.IOException: There is not enough space on the disk. : '\\xxx.file.core.windows.net\test\ReproFile'
   at System.IO.FileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite)
   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
   at System.IO.File.Copy(String sourceFileName, String destFileName)

• Copying the file via cp in Linux also errors with failed to close 'xxx': No space left on device

This problem only occurs in dotnet on Linux (reproduced on Debian 10, Ubuntu 18 & 20).

A related issue is that when running on this container mcr.microsoft.com/dotnet/core/runtime-deps:3.1 in Azure Kubernetes Service (AKS) and Ubuntu 18.04, the length of the file reported by FIleInfo is the untruncated size, which is wrong.

Reproduction

I have a console app at https://github.com/OctopusDeploy/AzureFileStorageRepro which will help with a minimal reproduction.

Configuration

Dotnet: v3.1.401
Windows 10: v10.0.19041.508
Linux distro's: Debian 10, Ubuntu 18.04, Ubuntu 20.04
Architecture: x64

Regression?

Unknown

Other information

I've previously logged an issue with Azure, which is suggesting that the problem might be closer to the dotnet runtime.

Screenshot of an Azure storage file share:

[danmosemsft]

This looks like it may be https://github.com/dotnet/runtime/pull/38742
Can you please try with 5.0 RC1?

[flin-8]

Hi @danmosemsft ,

Yes 5.0 RC1 does fix this (throws now) - thank you for the pointer.

Is there any appetite to backport this fix to 3.1? This is hurting us as we are now getting corrupt files randomly.

[danmosemsft]

Thanks for the info. We were waiting for customer evidence (I think). ... thoughts about risk here @carlossanlop ?

[danmosemsft]

Just curious @flin-8 are you likely to update to 5.0 when it ships in 2 months?

[flin-8]

Just curious @flin-8 are you likely to update to 5.0 when it ships in 2 months?

@danmosemsft the short answer is no.

The long answer is we will need to plan for the update and dedicate some time to stabilize and address any regressions arising from it. We only upgraded to 3.1 at the start of the year, so there's no definite timeframe for that at the moment.

[danmosemsft]

@flin-8 i fully understand. We’ll evaluate a port

[carlossanlop]

I think we can get this ported, I'll work on this today.

The involved code did not change between 5.0 and 3.1 (FileStream.Dispose and SafeFileHandle.ReleaseHandle). The only difference is that the fix lives in coreclr, and the manual tests in corefx, so I would have to submit two changes.

[carlossanlop]

@flin-8 I have a local fix for 3.1, see attached zip file.
Would you mind testing the DLL in your Linux x64 environment and letting us know if it worked?

Backup the original System.Private.CoreLib.dll located in this folder: $DOTNETINSTALL/shared/Microsoft.NETCore.App/3.1.0/System.Private.CoreLib.dll

Then extract the one in the zip file into that location.

System.Private.CoreLib.dll.zip

[flin-8]

@flin-8 I have a local fix for 3.1, see attached zip file.
Would you mind testing the DLL in your Linux x64 environment and letting us know if it worked?

Backup the original System.Private.CoreLib.dll located in this folder: $DOTNETINSTALL/shared/Microsoft.NETCore.App/3.1.0/System.Private.CoreLib.dll

Then extract the one in the zip file into that location.

System.Private.CoreLib.dll.zip

Yes the repro program is now throwing

One more thing I'm not sure about: is File.Copy() meant to clean up when it sees an error? It's leaving the file behind in Linux (running in Windows doesn't leave the file behind)

[carlossanlop]

No, the fix is not expected to delete the file if the exception is thrown. This is also the expected behavior in 5.0. The user should capture the exception and decide what to do with the file.

[carlossanlop]

Since this is already fixed in 5.0 and master, and we just need to backport to 3.1, I'll add the Future label.

[danmosemsft]

@carlossanlop i guess we can close now?

[carlossanlop]

Closing. It's been backported to 3.1: https://github.com/dotnet/corefx/pull/42988

[flin-8]

Thanks guys, appreciate it!

[flin-8]

@danmosemsft Do you know roughly when the 3.1 patch will be released?

[danmosemsft]

It should be in 3.1.9, which was released earlier this month. https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1.9/3.1.9.md