FlushFileBuffers required

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Our setup:
We run HORM with a two volume compact flash. Drive C: is read-only, Drive
D: is writeable. Drive D: is locked/unmounted prior to hibernation and then
unlocked immediately after hibernation.

Our problem:
We create/edit files on Drive D:. We always fflush() or fclose() the files
immediately after writing/changing any data in them, since we allow our
operators to power down any time they want and don't want to lose any data.
Our hope was that the files that we created/edited would alway be saved.
However, often aften a reboot, they disappear. I think it is because the
driver for the compact flash determines when to flush the file buffers,
independent of my fflush/fclose. I have found that if after every write I do
a FlushFileBuffers() everything seems to work. This seems to require quite a
bit of overhead, especially if I do a lot of writing. Is there a simpler
way, or am I missing something?
 
Drive D: is marked as fixed.

Disabling the write caching on D: did not have the effect that I hoped it
would It still appears to cache.

I'll look into the DiskCache tool. Thanks.
 
hanleyh1,

Well, there are still some internal buffers used by some API implementations :-(

Another idea.. You may want to call the FlushFileBuffers once in a while (not after each writing) for the entire volume (your drive
D:). The way to program that is:
- You open the volume (CreateFile( \\\\.\\D:)
- Pass the volume handle to FlushFileBuffers (this will do the sync for all the data on that volume that hasn't been flush out
yet)
- Close the handle

The above is part of what Windows typically does for a removal drive when you hit that "Safely remove hardware" icon in systray
(after that it should lock and dismount the volume but you don't need that).

This obviously doesn't fix the issue completely - you may still be losing some data if user powers down the device before the next
data flush. But, at least, you can make sure it is flushing frequently enough to minimize the loss.

If this would work for you, I'd suggest writing a separate agent app that called to FlushFileBuffers in a thread running in low
(idle) priority. Then it wouldn't affect the system performance much. Also, users typically tend to power down PCs intentionally
when they see no activities in software (not UI flicking) and hardware (no LEDs flushing and etc.).
 
I have essentially done what you are suggesting.

I have a timer which every five minutes causes a FlushFileBuffers() call,
which takes care of the key file that stays open at all times and I
separately call FlushFileBuffers() after I do a fclose() on new files
created. On top of that, the drive may occasionally do a FlushFileBuffers()
on its own (as it had leading me to discover this problem). So, all-in-all
my risk of losing data is minimized without having to call the function
constantly after each write.
 
Back
Top