Lets assume that exactly 1 byte after the File-1-EOF another file (file2) starts.

If I open up file 1 and use FileStream Filemode.Append, does it overwrite file2 or does it make another copy at a place where there is enough memory?

Thanks, in regards!

CodePudding user response：

You appear to be laboring under the misapprehension that files are stored sequentially on disk, and that extending one file might overwrite parts of another file. This doesn't happen when you go via a filestream append in c#. The operating system will write the bytes you add however it likes, wherever it likes (and it likes to not overwrite other files) which is how files end up broken into smaller chunks (and why defragging is thing) scattered all over the disk. None of this is of any concern to you, because the OS presents those scattered file fragments as a single contiguous stream of bytes to any program that wants to read them

Of course, if you wrote a program that bypassed the OS and performed low level disk access, located the end of the file and then blindly write more bytes into the locations after it then you would end up damaging other files, and even the OS's carefully curated filesystem .. but a .net file stream won't make that possible

TLDR; add your bytes and don't worry about it. Keeping the filesystem in order is not your job

CodePudding user response：

If I open up file 1 and use FileStream Filemode.Append, does it overwrite file2 or does it make another copy at a place where there is enough memory?

Thankfully no.

Here's a brief overview why:

Your .NET C# code does not have direct OS level interaction.

Your code is compiled into byte-code and is interpreted at runtime by the .NET runtime.

During runtime your byte-code is executed by the .NET Runtime which is built mostly in a combination of C#/C/C .

The runtime secures what it calls SafeHandles, which are wrappers around the file handles provided by what I can assume is window.h(for WIN32 applications at least), or whatever OS level provider for file handles you're architecture is running on.

The runtime uses these handles to read and write data using the OS level API.

It is the OS's job to ensure changes to yourfile.txt, using the handle it's provided to the runtime, only affects that file.

Files are not generally stored in memory, and as such are not subject to buffer overflows.

The runtime may use a buffer in memory to.. buffer your reads and writes but that is implemented by the runtime, and has no affect on the file and operating system.

Any attempt to overflow this buffer is safe-guarded by the runtime itself and the execution of your code will stop. Regardless, if a buffer overflow happened on this buffer successfully - no extra bytes will be written to the underlying handle. Rather the runtime would likely stop executing with a memory access violation, or general unspecified behavior.

The handle you're given is little more than a token that the OS uses to keep track which file you want to read or write bytes to.

If you attempt to write more bytes to a file than an architecture allows - most operating systems will have safe guards in place to end your process, close the file, or straight up send an interrupt to crash the system.