When using System.IO.FileStream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer?

[DR]

When using System.IO.FileS tream, I write 8 bytes, then seek to the start of
the file, does the 8 bytes get flushed on seek and the buffer become a
readbuffer at that point instead of being a write buffer?

[Michael Nemtsev [MVP]]

Re: When using System.IO.FileS tream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer?

Hello dr,

as I remember if u don't flush and reopen it again you can't seek it

---
WBR,
Michael Nemtsev [Microsoft MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo


dWhen using System.IO.FileS tream, I write 8 bytes, then seek to the
dstart of the file, does the 8 bytes get flushed on seek and the
dbuffer become a readbuffer at that point instead of being a write
dbuffer?
d>

[Patrice]

Re: When using System.IO.FileS tream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer?

Well, don't you have thought you could just try ?

My findongs are quite as expected that is :
- reading works (this is a buffer, reading a buffer you have written to is
not really a problem)
- content is not flushed on disk when seeking the origin. You can always
flush explictely if needed (but this is not needed to be able to read the
buffer)

You may want to explain what you are trying to do...


"DR" <softwareengine er98037@yahoo.c oma écrit dans le message de groupe de
discussion : OXu55uR8IHA.241 6@TK2MSFTNGP02. phx.gbl...

When using System.IO.FileS tream, I write 8 bytes, then seek to the start
of the file, does the 8 bytes get flushed on seek and the buffer become a
readbuffer at that point instead of being a write buffer?
>

[Anthony Jones]

Re: When using System.IO.FileS tream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer?

"Patrice" <http://www.chez.com/scribe/wrote in message
news:020D9BDA-BB88-4EE4-B8D8-911A9E122C54@mi crosoft.com...

Well, don't you have thought you could just try ?
>
My findongs are quite as expected that is :
- reading works (this is a buffer, reading a buffer you have written to is
not really a problem)
- content is not flushed on disk when seeking the origin. You can always
flush explictely if needed (but this is not needed to be able to read the
buffer)
>

My findings are different. Opening a file for read/write with shared read
causes will cause any written data to be flushed when Seek is used.
However an exclusive lock may cause the underlying OS API to make different
choices.

My adviced to DR (who has liberally multiposted this Q) is:-

>>

If you are worried that you might be overwritting data that
hasn't been stored yet then don't be.

If you want to make sure that data is persisted before doing other things
then you should explicitly flush. Just because seek appears to flush in a
the above case may simply be a result of specific OS decisions. In other
circumstances the underlying OS (on windows FileStream is a fairly
transparent wrapper on the Win APIs for these operations) may make other
choices.
<<

Which I posted in the dotnet.general group.


--
Anthony Jones - MVP ASP/ASP.NET

[Patrice]

Re: When using System.IO.FileS tream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer?

My findings are different. Opening a file for read/write with shared read

causes will cause any written data to be flushed when Seek is used.
However an exclusive lock may cause the underlying OS API to make
different
choices.

Ah yes !! I always find weird those kind of questions that looks to come out
from thin air, I didn't caught he might want to flush if reading from
another application. It always looks like to me like a strange obession to
know the gory details from an academic point of view ;-)

Once again it just show it's generally better for an OP to explain what he's
trying to do so that one could help achieving this goal rather than to work
the other way round and see if how things behave will fit his needs...

--
Patrice