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

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:

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (11 by maintainers)

Most upvoted comments

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

danmoseley on Oct 29, 2020

Thanks guys, appreciate it!

flin-8 on Sep 28, 2020

@carlossanlop i guess we can close now?

danmoseley on Sep 24, 2020

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 on Sep 17, 2020

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

flin-8 on Sep 17, 2020

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

danmoseley on Sep 17, 2020

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

danmoseley on Sep 17, 2020