`FileStream` Write has no effect when the file is deleted

[skyoxZ]

Description

Not sure if it's by design. FileStream Write has no effect when the file is deleted.

Reproduction Steps

using System.IO;

namespace FileStreamTest
{
    class Program
    {
        static void Main(string[] args)
        {
            string filePath = "a.txt";
            FileStream fs = new FileStream(filePath, FileMode.Create, FileAccess.ReadWrite, FileShare.Delete);
            File.Delete(filePath);
            fs.WriteByte(65);
            fs.Flush();
        }
    }
}

Expected behavior

Throw an exception.

Actual behavior

Not throw.

Regression?

I checked .NET 4.8 and it has the same behavior.

Known Workarounds

No response

Configuration

.NET 6.0.101
Windows 11 x64, 21H2

Other information

No response

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Not sure if it's by design. FileStream.Write has no effect when the file is deleted.

Reproduction Steps

using System.IO;

namespace FileStreamTest
{
    class Program
    {
        static void Main(string[] args)
        {
            string filePath = "a.txt";
            FileStream fs = new FileStream(filePath, FileMode.Create, FileAccess.ReadWrite, FileShare.Delete);
            File.Delete(filePath);
            fs.WriteByte(65);
            fs.Flush();
        }
    }
}

Expected behavior

Throw an exception.

Actual behavior

Not throw.

Regression?

I checked .NET 4.8 and it has the same behavior.

Known Workarounds

No response

Configuration

.NET 6.0.101
Windows 11 x64, 21H2

Other information

No response

Author:	skyoxZ
Assignees:	-
Labels:	area-System.IO, untriaged
Milestone:	-

[filipnavara]

This is how the operating system works. Deleting file is just a flag that sets the file to be deleted when all handles for it are closed. Since FileStream holds the handle it doesn't really get deleted until you close it.

[skyoxZ]

@filipnavara
After calling File.Delete, it's just like the file has been deleted: I can't see the file and I can Directory.CreateDirectory(filePath).
So I'm wondering what's the status of the handle and what happened when writing to that handle.

[danmoseley]

@skyoxZ I believe that's because, as @filipnavara says, if you're holding the handle already you don't see an effect; if you do not, you see it as deleted. I'm guessing we're using the API's correctly and it's just Windows behavior. Is it causing you a problem?

[danmoseley]

And of course if you remove FileShare.Delete then the delete should fail.

[skyoxZ]

@danmoseley Could you please explain more?

string filePath = "a.txt";
FileStream fs = new FileStream(filePath, FileMode.Create, FileAccess.ReadWrite, FileShare.Delete);
File.Delete(filePath);
Directory.CreateDirectory(filePath);
// break here
fs.WriteByte(65);
fs.Flush();

At the breakpoint, I observed the file disappeared from Explorer and a folder named a.txt successfully created. Is it normal?

Then what happened to the handle? Perhaps the handle becomes a blackhole that can still be used for Write & Flush but has no effect in reality?

[danmoseley]

That's really an OS question. Unless somehow we're overlooking a failure returned from the write, which you can check in the debugger.

[skyoxZ]

That's really an OS question. Unless somehow we're overlooking a failure returned from the write, which you can check in the debugger.

Even if it's Windows Write API behavior, I don't think there's no problem for .NET SDK because we are not just writing a WinAPI wrapper. I found the issue when using StreamWriter.Write and t's a big surprise that it runs without exception when the underlying file has been deleted.

[danmoseley]

I'll let the IO area owners respond. (@jkotas do you happen to be familiar with Windows behavior here?)

[jkotas]

That's how file systems work, on both Windows and Unix.

Something to consider: Hard links allow you to create multiple file names for the physical file. It means that one physical file can have one or more file names. Allowing zero filenames for the physical file is very natural extension of this concept in the operating systems. It does not make sense for .NET file I/O API to behave differently. It would be breaking, complex and unreliable for .NET to file I/O APIs to try to implement different behavior.

Perhaps the handle becomes a blackhole that can still be used for Write & Flush

You can still use the handle for reading as well. This technique is frequently used with temporary files: Create and open temporary file, delete the temporary file, and keep using the file handle to read and write for as long as necessary. The physical file will be deleted when the handle is closed.