Member Avatar for seeppms

I am using filepointer in C. when I compile the code
and run it for the first time the filepointer works fine and
logs are written into log files. But during next hits there is an
inconsistency in logs getting written. sometimes getting written
and someother times not written. But during all those times
the file pointer returns a valid integer.

So I tried to close the file pointer and opened again before writing into logs now it works fine during all execution.

Can anybody explain me what was the exact problem, how can
I fix that without closing and opening again as it is occuring at
some time and not in an inconsistent way.

  • 3 Contributors
  • 4 Replies
  • 182 Views
  • 12 Hours Discussion Span
  • Latest Post Latest Post by WaltP

Dani AI

Generated

observed a classic symptom: first run writes appear, later runs are intermittent, and reopening the file fixed it. That behavior most commonly comes from three separate causes (often combined): stdio buffering (data stays in the user-space buffer until flushed or closed), external rotation/replacement of the logfile (the old FILE* keeps writing to the renamed/unlinked inode), and concurrent access (multiple processes/threads writing without proper append semantics or locking). was right to recommend closing when done as a pragmatic fix; however the claim that merely leaving a stream open is "undefined behaviour" is too strong — the C library defines buffered behavior, but visibility/durability depends on flush/close, program termination, and external file-system events (which is what was asking for).

Practical checks and a minimal robust pattern:

  • Open in append mode so writes are appended, not overwritten.
  • Check every I/O return value and use ferror() / perror() to detect problems.
  • Flush after important log entries with fflush(); if persistence to disk is required, call fsync(fileno(fp)) (costly).
  • If the process is long-lived and the file may be rotated, detect rotation (inode change) and reopen the new filename.

Example sketch (conceptual):

FILE *fp = fopen("app.log", "a");
if (!fp) { perror("fopen"); /* handle */ }
if (fprintf(fp, "%s\n", line) < 0) perror("fprintf");
if (fflush(fp) != 0) perror("fflush");
int fd = fileno(fp);
if (fd >= 0) fsync(fd);   /* optional, expensive */
fclose(fp);

Notes on concurrency and rotation: for multiple processes prefer open(2) with O_APPEND and write(2) for atomic small writes, or use file locks (flock/fcntl). If a log-rotator renames the file, the original FILE* still points at the old inode; reopening after rotation or using "copytruncate" options (or letting the logger reopen on SIGHUP) is necessary. Checking I/O return codes and deciding between per-write open-vs-keep-open (with fflush) will eliminate the intermittent loss seen by .

Recommended Answers

All 4 Replies

Member Avatar for ~s.o.s~

Its normally a rule of the thumb to close the file pointer as soon as you are finished with it to avoid the undefined behaviour of the file stream which you have opened. Even if you dont close the file stream, they are automatically closed when your program exits but is regarded as a bad practice and may cause subtle bugs due to the corruption of the open file stream. Hence better close the file stream as soon as you are done wiht it rather than waiting for them to be automatically closed.

And btw file poitner returning valid integer as you say means that the file pointer exists and is pointing to the file currently opened but doesnt necessarily guarantee defined behaviour.

Hope it helped, bye.

Member Avatar for seeppms

Thanks SOS,

So you mean to say even if the file pointer points to the file,
it may not write into it at times..as it was kept opened.

Member Avatar for ~s.o.s~

It is not called not writing into the files, as mentioned by me earlier, it is called undefined behaviour when the file stream is kept open.

Undefined behaviour can imply successful write as well as an unsuccessful write, but cant be determined when that happens. Use the funtion int ferror (FILE* file_ptr) to check whether the file stream is corrupted or not.

HOpe it helped, bye.

Member Avatar for WaltP

Its normally a rule of the thumb to close the file pointer as soon as you are finished with it to avoid the undefined behaviour of the file stream which you have opened.
----
It is not called not writing into the files, as mentioned by me earlier, it is called undefined behaviour when the file stream is kept open.

Undefined behaviour can imply successful write as well as an unsuccessful write, but cant be determined when that happens. Use the funtion int ferror (FILE* file_ptr) to check whether the file stream is corrupted or not.

I'm not sure what you are saying here. It looks like you are saying if a file is not closed you enter the realm of undefined behavior. This is the first I've heard this. Can you point out something that substantiates this view?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.