Patrice said:
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.