FileStream security issue

[Day]

Hey, all.
I know this is a rather awkward question, but I'd love some insight
about this if anyone here has such to offer.
In my system, I'm copying files using a buffer system of a sort. I
copy such and such bytes from FileStream fsA using Read, and write the
amount read to FileStream fsB using Write.

My question is as following -
What are the odds that during the Read function, I'll have an
"overflow" of a sort? Say, the stream is pointing towards MyFile.txt,
as well as the first few bytes of HisFile.xml.
Or, alternatively, it doesn't, but I gave it "too much" to read so it
simply helped itself to a bit of the next file.

From experience, that sort of thing doesn't really happen and I've
seen nothing eye-catching in the matter on the net, but that could
just be me being wishful thinking and I can't really afford it.
So. Am I being an insane paranoid for no reason, or does me being
paranoid not mean I'm not being chased?

Thank you for any input you might have for me.

Cheers,
~Day

 

[Jeroen Mostert]

I know this is a rather awkward question, but I'd love some insight
about this if anyone here has such to offer.
In my system, I'm copying files using a buffer system of a sort. I
copy such and such bytes from FileStream fsA using Read, and write the
amount read to FileStream fsB using Write.

My question is as following -
What are the odds that during the Read function, I'll have an
"overflow" of a sort? Say, the stream is pointing towards MyFile.txt,
as well as the first few bytes of HisFile.xml.

This is impossible. A file stream operates on logical files, not physical
disk sectors. A stream reading "MyFile.txt" can never read any other file.
This is enforced on the operating system level. It has to be, because it
would be a security violation if you were able to peek at another file by
reading some stray bytes.

Interesting lateral thinking, but you'll have to trust abstractions more if
you don't want to be continuously distracted by things like this.