file size c is different than the size data string's size

Question

I have a file I'm writing to and then changing the size of it to the size of text written to it something like:

FILE * file...

I get all the data from the file and change the file's size to the data's size but it differs. The string's size is smaller then the filelength and it cuts it and loses data. What might be the problem?

while(fgets(cLine, sizeof(cLine), file) )
    str.append((string)cLine);
fputs(str.c_str(),file);
_chsize( fileno(file), (int)str.size() );

When I checked it always fileLength(fileno(file)) is larger than str.size()!

Answer 1

Perhaps it's CRLF? Beware of:

fopen(filename, "r") vs fopen(filename, "rb"),

and likewise

fopen(filename, "w") vs fopen(filename, "wb").

The reason is because "r" or "w" will translate CRLF, while "rb" or "wb" will treat the data as binary. On most platforms this is ignored. For instance, the fopen man page on OS X:

The mode string can also include the letter "b" either as a third character or as a character between the characters in any of the two-character strings described above. This is strictly for compatibility with ISO/IEC 9899:1990 ("ISO C90") and has no effect; the "b" is ignored.

The fopen page on MSDN says something different:

b

Open in binary (untranslated) mode; translations involving carriage-return and linefeed characters are suppressed.

If t or b is not given in mode, the default translation mode is defined by the global variable _fmode. If t or b is prefixed to the argument, the function fails and returns NULL.

For more information about using text and binary modes in Unicode and multibyte stream-I/O, see Text and Binary Mode File I/O and Unicode Stream I/O in Text and Binary Modes.

Answer 2

Depending on what you are doing in your code for cr/lf and what OS you are running, there could be some translating happening in the background when you read/write the file if you open it in text mode.

Answer 3

Jonathan has hit the nail on the head.

Ensure that you are reading the file in binary format or if you are certain that the file only contains text (and that is all that you want) then be prepared for file characters to be in unicode or some other format.

You'll also find that extra control characters will be automatically added not least the EOF character.

My question though is why do you read the data from the file, only to write it back in again?