file opperations stop after 90 or so reads

[GNTMDjzh]

i am completely baffled at this problem. what i want to do is simple (well, this one part anyways. the problem is part of a much bigger project), i want to open one file that already exists. i want to create a blank file that whose name is the name of the existing one, but with a 2 on the end. i want to read one character from the existing file, and write it to the new one. i want to do this for every byte in the existing file. this works until about the 90th character, whereupon the output file either has null terminators for the rest of the file, or a random character. my code is simple, and as follows:

#include <stdio.h>

int main()
{
	FILE * srcF = fopen("testFile", "r");
	if(srcF == 0)
	{
		fprintf(stdout, "error: file missing, press enter to exit");
		while(1)
		{
			if(fgetc(stdin) == (int)'\n') return 0;
		}
	}
	FILE * destF = fopen("testFile2", "w");
	fseek(srcF, 0, SEEK_END);
	long size = ftell(srcF);
	fseek(srcF, 0, SEEK_SET);
	for(long a = 0; a < size; a++)
	{
		fputc(fgetc(srcF), destF);
	}
	fclose(srcF);
	fclose(destF);
	return 0;
}

(testFile is a renamed openoffice document from a while ago)


testFile2 is identical to testFile, until about character 90, whereupon it is just one character, random each run, to the end.

[Dudester]

What kind of data is in the file?

[GNTMDjzh]

well, when one looks at it in notepad, it is simply gibberish mixed in with file paths. i simply copied a random file from the "My documents" folder, and renamed it. when comparing the two files after a run, the original seems to have some semblance of data, while the copy has about one line of identical characters, and then one single character repeated until the end.

[Dudester]

I had a similar problem. I noticed that characters from the extended ASCII set don't play nice with the C++ and C standard libraries. My suggestion would be to look at another library for your IO needs.

[LB]

Maybe it's null characters?

[Dudester]

I've noticed that it doesn't have to be null characters. Atleast in my case when I debugged it the values that always stopped the program were null characters and characters that evaluated to negative numbers in the ASCII set. This means that there are UNICODE values in the file that are causing problems.

[dineshcpp]

which environment r u using??? is it windows????
In my environment your code works fine. i m using VS 2005 on windows.

[Dudester]

@dineshcpp
What kind of file did you try it on? Test it on an executable or something with strange file data that is not human readeable.

[GNTMDjzh]

an old open office document, so yes, not human readable character-wise. i would have thought that any file would be stored byte by byte, so encoding would not matter if all i cared about was that the data got from one place to another, not caring about content.

[Dudester]

The C library sets an error flag when it encounters a non-ASCII value which is where your problem is coming from.

[chrisname]

If it's not ASCII-encoded and you're on Windows, you need to open it with the binary flag ("rb" instead of "r", "wb" instead of "w").

[kbw]

You don't check for fgetc returning -1.
Why would you do byte by byte copy anyway? Use block reads/writes, which in your case is fread/fwrite.

[chrisname]

You should check for fgetc() returning EOF, not -1; while EOF is probably -1 it's safer to check for EOF.