BinaryReader.ReadBytes issue

[Jon Skeet [C# MVP]]

Is 2GB the largest file size on NTFS?

I don't think so. I'm pretty sure they're not, actually.

Just curious why the read methods are limited to int.maxvalue and not
long.

Well, as I said, it's very *very* rarely a good idea to read in that
much of a file at a time. If you've got a file that big, you're much
more likely to be scanning through it or seeking into it.

The usage model may well change in the next ten years, of course, as 64
bit systems become more prevalent, and memory and disks become faster
and cheaper.

 

[Guest]

Is 2GB the largest file size on NTFS? Just curious why the read methods are
limited to int.maxvalue and not long.


take

Just use the FileStream then , no need for memory or binary streams


fs = new FileStream(filename, FileMode.Open);

byte[] ba = null;
if (fs.Length <= int.MaxValue)
{
fs.Read(ba, 0, (int)fs.Length);
}
else
{
throw new InvalidOperationException("File size too large, above "
+ int.MaxValue + " bytes");
}

 

[Jon Skeet [C# MVP]]

Just use the FileStream then , no need for memory or binary streams


fs = new FileStream(filename, FileMode.Open);

byte[] ba = null;
if (fs.Length <= int.MaxValue)
{
fs.Read(ba, 0, (int)fs.Length);
}
else
{
throw new InvalidOperationException("File size too large, above "
+ int.MaxValue + " bytes");
}

This time you *do* need to initialise the array first, because you're
telling Stream.Read where to read into.

However, you're then assuming that FileStream.Read will read everything
you ask it to, which it isn't guaranteed to. Assuming that Stream.Read
reads as much as you've asked it to as a maximum has been the cause of
many a developer getting corrupted data.

 

[Guest]

Yeah i know, I do that.

Just use the FileStream then , no need for memory or binary streams


fs = new FileStream(filename, FileMode.Open);

byte[] ba = null;
if (fs.Length <= int.MaxValue)
{
fs.Read(ba, 0, (int)fs.Length);
}
else
{
throw new InvalidOperationException("File size too large, above "
+ int.MaxValue + " bytes");
}

This time you *do* need to initialise the array first, because you're
telling Stream.Read where to read into.

However, you're then assuming that FileStream.Read will read everything
you ask it to, which it isn't guaranteed to. Assuming that Stream.Read
reads as much as you've asked it to as a maximum has been the cause of
many a developer getting corrupted data.

 

[Guest]

And binary reader gurantees its all read at once?

Just use the FileStream then , no need for memory or binary streams


fs = new FileStream(filename, FileMode.Open);

byte[] ba = null;
if (fs.Length <= int.MaxValue)
{
fs.Read(ba, 0, (int)fs.Length);
}
else
{
throw new InvalidOperationException("File size too large, above "
+ int.MaxValue + " bytes");
}

This time you *do* need to initialise the array first, because you're
telling Stream.Read where to read into.

However, you're then assuming that FileStream.Read will read everything
you ask it to, which it isn't guaranteed to. Assuming that Stream.Read
reads as much as you've asked it to as a maximum has been the cause of
many a developer getting corrupted data.

 

[Jon Skeet [C# MVP]]

And binary reader gurantees its all read at once?

Yes, although it's not as clear from the documentation as it might be
what the difference between Stream.Read and BinaryReader.ReadBytes is.

 

[Guest]

All the streams do not gurantee reading all the maximum count requested so
you are not guranteed any way you chose except testing the retval of the
..Read method to be sure.

And binary reader gurantees its all read at once?

Just use the FileStream then , no need for memory or binary streams


fs = new FileStream(filename, FileMode.Open);

byte[] ba = null;
if (fs.Length <= int.MaxValue)
{
fs.Read(ba, 0, (int)fs.Length);
}
else
{
throw new InvalidOperationException("File size too large, above "
+ int.MaxValue + " bytes");
}

This time you *do* need to initialise the array first, because you're
telling Stream.Read where to read into.

However, you're then assuming that FileStream.Read will read everything
you ask it to, which it isn't guaranteed to. Assuming that Stream.Read
reads as much as you've asked it to as a maximum has been the cause of
many a developer getting corrupted data.

 

[Guest]

MSDN states that binaryreader does not gurantee , just the same as
FileStream doesnt.

 

[Jon Skeet [C# MVP]]

MSDN states that binaryreader does not gurantee , just the same as
FileStream doesnt.

No, not "just the same" - it only says it will return fewer bytes if it
reaches the end of the stream. You don't have to reach the end of the
stream to have fewer bytes returned to you with Stream.Read. In
practice, I suspect that FileStream.Read *will* always act like
BinaryReader.ReadBytes, but other streams won't (particularly those
over networks), and it's good to avoid getting into the habit of
relying on it.

 

[Bram]

Hi,

I find this conversation kinda sad, Jon.
You gave him lots of good information and tips, while he did not want to
listen.
Keep up the good work.

Cheers,

Bram