views:

64

answers:

2

I'm writing an application whose purpose involves a lot of logging of different events. Among those I would also like to have an event that the application was shut down - even if unexpectedly like because of a power loss.

Naturally, when the power goes out I don't get a chance to write anything anywhere. So my idea was to continuously write a timestamp in some known location (say, once per minute), and when the application was next run, it could determine the approximate time of the unexpected shutdown. A precision of 1 minute would be acceptable for me.

However I'm worried that caching at the OS and disk level might interfere with this approach. Is there a better way or if not - how to make sure that the data I just wrote is REALLY written out to the physical medium?

Added: Oh, almost forgot the buzzword line: Windows XP and above; .NET 3.5; C#.

+1  A: 

Edit: removed the incorrect answer (due to not reading the question properly)

You could use the FlushFileBuffers method, but that will still only write it to the device, you still can't get the actual drive to write it (as far as I know).
http://www.pinvoke.net/default.aspx/kernel32/FlushFileBuffers.html?diff=y

ho1
No, that only flushes the internal buffer of FileStrem, not the OS cache.
Vilx-
If you were worried about milliseconds or seconds I could see why you'd worry about this but I've never experienced that the OS/Disk would hold tiny stuff in cache for minutes without writing it. It might happen in exceptional circumstances or in strange configurations but I'd thought it would be very unusual.
ho1
Well, I couldn't find any documentation about this. Indeed, if I could be sure that it would be flushed in a few seconds, that would be fine. Otherwise I thought it could be held there indefinitely. And since the file would be extremely small and very often accessed, I figured it would have a very good chance of staying in the cache forever (until the system shuts down).
Vilx-
I'm not an expert on this but I think you're thinking about it the wrong way around. MS would get in a lot of trouble if people kept loosing data that they've already saved if the computer crashes after the save.
ho1
@ho: Write-Behind Caching (http://www.eduadmin.com/oplock.htm)
Jonners
Fair point. In that case the call to `Flush()` isn't even needed - `Close()` should be enough I think.
Vilx-
@Jonners - interesting in general, though I don't think it's relevant for this discussion since I assume that the high traffic mentioned would be quite a lot more than one timestamp per minute.
ho1
+2  A: 

Unexpected shutdowns are logged in the system event log.

When your application shuts down cleanly, write it to your logfile. Next time your application starts check if your application was shut down the way it supposed to, otherwise check the system event log.

ZippyV
An application can be shut down unexpectedly in many ways.
Vilx-
And most of those unexpected shutdowns are logged into the system/application event log.Checking the event log is still a better idea than writing timestamps every minute.
ZippyV
I mean that the application could also crash or be terminated or something. That would not get logged anywhere.
Vilx-
If it crashes it's logged into the application event log, if it's terminated then Windows will send a message to your app which you should be able to handle.
ZippyV
+1. If your app crashes then you'll get a minidump telling you exactly why. If the computer loses power, there will be an event indicating unexpected shutdown. Much more information than is available if you just 'touch' a file periodically.
Jason Williams
Can you then list all the things I should check/monitor to cover every possibility?
Vilx-
Recreate every possibility and then check your application or your system event log. Keep in mind that category id's could have been changed between XP and Vista/7.
ZippyV
I'm sorry, but I don't know every possibility. That's why I asked you for the list...
Vilx-