fseek does not work when file is opened in "a" (append) mode

Question

FILE* f = fopen("rajat", "w");
fputs("sometext", f);
fseek(f, 6, SEEK_SET);
fputs("is a", f);
fclose(f);

Successfully returns: "someteis a"

But

FILE* f = fopen("rajat", "a");
fputs("sometext", f);
fseek(f, 6, SEEK_SET);
fputs("is a", f);
fclose(f);

Does not work. Returns "sometextis a"

Any ideas why? What is the solution to this, so that the second code outputs exactly like the first?

Ruvolo

Don't you need "w+" for the first one? Otherwise the file is destroyed and recreated. – Goldofpleasure

Answer 1

When you open in append mode, the file pointer is returned to the end of file before every write. You can reposition the pointer with fseek for reading, but as soon as you call a function that writes to the file, the pointer goes back to the end of file.

Or, putting it another way, to prevent loss of data, the position of the "write pointer" overrides the position of the "read pointer". After any append, the write pointer bounces to the new EOF.

The answer at this link references the appropriate section of the C standard.

Use the "w+" mode if you would like to write to arbitrary places in file. An existing file will be overwritten.

If you would like to append to an existing file initially, but then fseek to arbitrary place, use "r+" followed by fseek(f, 0, SEEK_END).

Propositus

If you don't want existing data in the file to be destroyed, you should use "r+", not "w+". – Embrue

@JamesKanze This is correct, I clarified this point in an edit a few minutes back. A drawback for r+ is that the file must exist, though. – Propositus

I've always found that behavior of "a" to be non-intuitive. – Oxysalt

@MichaelBurr The behavior of "a" is designed to support things like log files which are (or might be) written from several different processes. The seek to the end should be atomic (if possible); on a Unix platform, the file will be opened with the "O_APPEND" flag. The user code then ensures that the stream has a sufficiently large buffer, outputs a log record, and calls fflush to write it. – Embrue

"As soon as you call a function that writes to the file, the pointer goes back to the end of file" Great. Can we say "Once a function has appended to the file, the pointer goes back to the (new) end of file"? – Bipropellant

@LaurieStearn Sounds like a good edit suggestion. Click "suggest edit" link, and edit the answer; I'll be happy to accept your edit. Thank you! – Propositus

dasblinkenlight: Only to happy to- but here as a comment: To prevent loss of data, the position of the "write pointer" overrides the position of the "read pointer". After any append, the write pointer bounces to the new EOF. – Bipropellant

@Rajesh This would be a great question in its own right. Please consider asking a question, and provide your code as a minimal example. Explain how you expect ftell to give the size of non-empty "1.txt", but that you get zero instead. I think you'll have a well-received question. – Propositus