How to make fwrite() consistent in writing data to a file?

FAT32 is not a journaling filesystem so there is no way to guarantee consistent writes. Even if you flush the disk buffers after each write, the data could still be corrupted if there is a power loss just as the data is written to disk To answer your other question, no, the garbage isn't caused by fwrite at all, it is because the filesystem has not completed the write operation in its entirety.

FAT32 is not a journaling filesystem, so there is no way to guarantee consistent writes. Even if you flush the disk buffers after each write, the data could still be corrupted if there is a power loss just as the data is written to disk. To answer your other question, no, the garbage isn't caused by fwrite at all, it is because the filesystem has not completed the write operation in its entirety.

Although, if it were important enough, you could implement some basic journalling features within your output format. – Dana the Sane May 19 at 16:31 @Dana the Sane: Correct, and I think that's the best the OP can do in this situation. – casablanca May 19 at 16:32 3 Alternatively, since this seems to be an embedded system, OP could try to alter the hardware requirements to include a big enough capacitor or battery to ensure that writes can be completed after a "power failed" signal occurs.

However this might be an unacceptable increase in cost. On the other hand if you're already using a batter, you just need to monitor it better... – R.. May 19 at 16:57.

Right after writing, call fflush(3) (to flush user-space buffers), and then either fsync(2) or fdatasync(2) to make sure that all the data has been written to the device.

I am writing one line at a time of 200 chars aprprox. – Punit May 19 at 16:22 1 It will, but it's the only way a user-space program can instruct the kernel to write all the data to disk. You may also consider calling fsync(2) at larger periods.

– Blagovest Buyukliev May 19 at 16:25 1 @Punit: Of course it will. This is the cost of trying to tell the C library and operating system what to do. – Matt Joiner May 19 at 16:26 The OP just explained he isn't using a standard C implementation, nonetheless I upvoted this because of it's application to ISO C.

– jedwards May 19 at 17:20.

It depends what implementation of FAT your embedded OS is using. If you're using smxFS, then you should take advantage of the following: The DOS/Windows FAT file system is inherently not power fail safe, so smxFS implements features to compensate for this: 1. Sfs_chkdsk() API can check and fix many problems, such as cross-linked files, lost chains, bad directory entries, and other problems.

Flags specify which types of problems to fix (or none). It indicates the results using flags in the return value and can give detailed text information in a buffer, to allow a human operator to correct problems. Please see the smxFS User’s Guide for details.2.

Clean shutdown checking determines whether all files were closed and caches flushed before the system shut down. If not, sfs_chkdsk() should be called. If you expect unexpected power losses, you should consider a capacitor or backup battery that will allow you to finish a write correctly.

You'd probably want sfs_fflush and sfs_fclose (or maybe even sfs_fclose, as it looks like it flushes itself) There are other filesystem options listed here, although they might not all be suitable for your application as not all of them can be read OOB by a computer.

I am using exactly what you have mentioned above but sfs_chkdsk() doesn't help me in fixing file(garbage values etc) issues, it could fix file system issues though. – Punit May 19 at 18:02.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.