tags:

views:

216

answers:

4

Hello,

I have a binary file. It consists of 4 messages, each is inthe size of 100 bytes. I want to read that last 2 messages again. I am using BinaryReader object. I seek to psosition 200 and then I read: BinaryReaderObject.read(charBuffer, 0, 10000), where charBuffer is big enougth. I get all the time the a mount of read is always missing 1. Instead of getting 200 I get 199. Instead of getting 400 I get 399. I checked and saw the size of the file is correct and the data that I get starts at the right place.

Thnaks,

+1  A: 

Hint: zero-based array indexes, and zero-based positions ... First byte will start at position zero.

Frederik Gheysels
Right. I was thinking the same, but I think the numbers are ok (i.e. first record starts at 0 and goes to 99, second record starts at 100, goes to 199, etc...). Seeking to position 200 seems like the right place for the start of the 3rd record.
Erich Mirabal
Where do u mean zero based, in the file in what I read ?As I said I get data starting correctly, and the amount of data that I get back is missing onr
Roman Dorevich
Computers count from zero. The first element in an array is 0, the second is 1, etc. This is called a zero-based array; because it starts at zero. Files are treated as zero-based arrays of bytes, hence position 200 is the 201st byte by 'normal' counting, explaining the off-by-one error you are encountering.
Matthew Scharley
I don't want to downvote -- but I really think this is wrong. If I am at position 0 and then read 1 byte, I am at position 1. If I am at position 0 and read 100 bytes, I am at position 100. The Nth record (1st, 2nd, 3rd) is at (N-1) * 100 -- the 0 based refers to the number you multiply by the record size.
Lou Franco
He isn't just reading 200 bytes, he's **seeking** to position 200 then trying to read 200 bytes, hence the off-by-one.
Matthew Scharley
@Matthew: And position 200 (the 201st byte) should be the first byte of the third chunk.
LukeH
Right... I knew there was a reason I didn't make my own file formats. Also, t'is late. I need to stop procrastinating sleep.
Matthew Scharley
-1. I will downvote. Roman already stated that he is getting the right beginning of the record. We are beating this off-by-one to death. The position `200` is the right place for the 3rd record to start (as others have already commented as well. it looks like this [0..99][100..199][200..299][300..399]...).
Erich Mirabal
+1  A: 
  1. Seek to the end and print position. Is it as expected?
  2. Print the position after reading the 199 -- is it as expected?
  3. Try to read 1 more byte from the position after you get 199 -- do you get EOF?
  4. How are you checking the size of the file?
  5. Diff the 199 bytes with the expected ones -- what is different?

Two things I would check

  1. CR/LF transformations
  2. That the size is what you think it is.
Lou Franco
If it is a "binary" file, `CR/LF` shouldn't make a difference. But I think that you might be onto something if he is using strings and the encoding might affect the size.
Erich Mirabal
A file isn't binary or text -- it's how you open and read it.
Lou Franco
He is talking about 100-byte records appended to a file. He called it a binary file. I was quoting him. All files are binary (as opposed to analog), but yes, whether or not it is "binary" or "text" is up to the reader on how he decodes the data.
Erich Mirabal
+5  A: 

Try this code and see what happens with your file.

 String message = @"Read {0} bytes into the buffer.";

 String fileName = @"TEST.DAT";

 Int32 recordSize = 100;

 Byte[] buffer = new Byte[recordSize];

 using (BinaryReader br = new BinaryReader(File.OpenRead(fileName)))
 {
    br.BaseStream.Seek(2 * recordSize, SeekOrigin.Begin);

    Console.WriteLine(message, br.Read(buffer, 0, recordSize));
    Console.WriteLine(message, br.Read(buffer, 0, recordSize));
 }

 Console.ReadLine();

I get the following output with a 400 byte test file.

Read 100 bytes into the buffer.
Read 100 bytes into the buffer.

If I seek to 2 * recordSize + 1 or use a 399 byte file, I get the following output.

Read 100 bytes into the buffer.
Read 99 bytes into the buffer.

So it works as expected.

Daniel Brückner
A: 

The problem was that I used a wrapper to BinaryReader object. When calling the Read method there are some function overloding. Instead os using the signeture of char[], I used byte[]. Till now it worked fine because there was only use of utf-8, but now when I entered real binary data in the beginning of each message it caused the problem.

Roman Dorevich