2

I'm trying to read from a file at a specific offset (simplified version):

typedef unsigned char u8;
FILE *data_fp = fopen("C:\\some_file.dat", "r");
fseek(data_fp, 0x004d0a68, SEEK_SET); // move filepointer to offset
u8 *data = new u8[0x3F0];
fread(data, 0x3F0, 1, data_fp);
delete[] data;
fclose(data_fp);

The problem becomes, that data will not contain 1008 bytes, but 529 (seems random). When it reaches 529 bytes, calls to feof(data_fp) will start returning true.

I've also tried to read in smaller chunks (8 bytes at a time) but it just looks like it's hitting EOF when it's not there yet.

A simple look in a hex editor shows there are plenty of bytes left.

Daniel Sloof
  • 12,568
  • 14
  • 72
  • 106

4 Answers4

5

Opening a file in text mode, like you're doing, makes the library translate some of the file contents to other stuff, potentially triggering a unwarranted EOF or bad offset calculations.

Open the file in binary mode by passing the "b" option to the fopen call

fopen(filename, "rb");
pmg
  • 106,608
  • 13
  • 126
  • 198
1

Is the file being written to in parallel by some other application? Perhaps there's a race condition, so that the file ends at wherever the read stops, when the read is running, but later when you inspect it the rest has been written. That would explain the randomness, too.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • nope! it was being read by another application but closing it or even copying the file and changing the path gives me the same result... oddly enough that random number (529) is the same each and every time – Daniel Sloof Dec 14 '10 at 16:22
1

Maybe it's a difference between textual and binary file. If you're on Windows, newlines are CRLF, which is two characters in file, but converted to only one when read. Try using fopen(..., "rb")

Milan Babuškov
  • 59,775
  • 49
  • 126
  • 179
0

I can't see your link from work, but if your computer claims no more bytes exist, I'd tend to believe it. Why don't you print the size of the file rather than doing things by hand in a hex editor?

Also, you'd be better off using level 2 I/O the f-calls are ancient C ugliness, and you're using C++ since you have new.

int fh =open(filename, O_RDONLY);
struct stat s;
fstat(fh, s);
cout << "size=" << hex << s.st_size << "\n";

Now do your seeking and reading using level 2 I/O calls, which are faster anyway, and let's see what the size of the file really is.

Dov
  • 8,000
  • 8
  • 46
  • 75
  • In most cases the f-calls are faster because they are buffered, while low-level is unbuffered. In this case it doesn't matter, though, since there is only one read. – Sergei Tachenov Dec 14 '10 at 17:41
  • IF you want speed, don't use old, crufty C api that has layer upon layer of junk in it. If you are doing lots of reads, you need a high performance buffering class, yes. – Dov Dec 14 '10 at 18:31