FileStream problem

  • Thread starter Thread starter Mike Robinson
  • Start date Start date
M

Mike Robinson

The Win32 SDK had a great function called "ReadFile" that was a model of
simplicity. Now I'm starting to use the new .NET Framework, which is
supposed to be an improvement but the file reading is (as far as I can tell)
nowhere near as good.

FileStream fs=new FileStream(FName);
fs.BeginRead (Buffer,0,thisFile.Length,0,0);

The last two arguments (the two closing zeroes) are for "AsyncCallback" and
"stateObject." Microsoft's documentation does not clarify what these should
be. Can anybody clear this up?

I would like to read an entire (small) file of integers into a buffer in one
read. Can that be done? MSoft, you need to do more work on file reading,
it's not very useful in its current state.

Thanks very much for any help.
 
Mike Robinson said:
The Win32 SDK had a great function called "ReadFile" that was a model of
simplicity. Now I'm starting to use the new .NET Framework, which is
supposed to be an improvement but the file reading is (as far as I can tell)
nowhere near as good.
Click to expand...

I believe that's really just because you don't know the framework
particularly well.
FileStream fs=new FileStream(FName);
fs.BeginRead (Buffer,0,thisFile.Length,0,0);

The last two arguments (the two closing zeroes) are for "AsyncCallback" and
"stateObject." Microsoft's documentation does not clarify what these should
be. Can anybody clear this up?
Click to expand...

If you read up on AsyncCallback or Asynchronous IO (the latter of which
is linked at the bottom of the page) you'll have much more idea.
I would like to read an entire (small) file of integers into a buffer in one
read. Can that be done? MSoft, you need to do more work on file reading,
it's not very useful in its current state.
Click to expand...

It's perfectly fine in its current state.

Now, do you really need to read asynchronously? It doesn't sound like
you do - so just call Read instead of BeginRead. There's no guarantee
that FileStream will read the whole file in one go, however, so you may
need to loop round filling the buffer appropriately. It's not hard
though.
 
Hi Mike,

Well, I would suggest that before posting you do a quick search on MSDN,
there you will see that there is two forms of using a FileStream , an
asynchronic and a syncronic ( this latter is the "normal" form ) , using
async allow you to continue to do other things while you are reading/writing
after the operation finish a method is called to inform of it. for this you
use BeginRead/EndRead methods


The other way is the old/plain and easy to use Read() method , that has the
signature that you expect ( look for it in the MSDN )

Of course you can read an entire file in once operation. just create a
buffer big enough.


Hope this help,
 
Hi again Mike,

Here you will get some code for what you want, you will find a "problem"
basically that you want to fill a int[] but FileStream.Read expect a byte[]
therefore you need to convert it. I dig this code from an old file, hope it
helps you.

Pd: You will have to try it, I cannot assure it works cause I did not write
it in the first place.

FileStream fs = File.OpenRead( @"c:\Test\data.bin" );
int length = (int)fs.Length; //size in byte
int[] targetArray = new int [length /4]; an int is a 32 bit animal, aka 4
bytes long
byte[] buffer= new byte[length ];
fs.Read( buffer, 0, length );
System.Buffer.BlockCopy( buffer, 0, targetArray, 0, length );


Hope this help,
 
Ignacio Machin said:
Of course you can read an entire file in once operation. just create a
buffer big enough.
Click to expand...

That doesn't guarantee that it'll read the whole file. From the docs:

<quote>
An implementation is free to return fewer bytes than requested even if
the end of the stream has not been reached.
</quote>
 
Ignacio Machin said:
Yes you are right, the doc say that, now I wonder why ?
Click to expand...

Well, it makes sense to read progressively in many situations - if
you've read everything the disk has given you, you (the OS/library
writer) might as well request more and have the disk spin and fetch it
while the caller is processing the first chunk.

I suspect it doesn't happen for smallish files, but I wouldn't be
surprised to see it happen for absolutely enormous files.
 
Back
Top