LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Corrupt files when PC crashes

Hello everyone,

 

In my applications (labview executable) I use files on local drive for storing data about the execution (basically a log file of some sort).  When for some what ever reason (e.g. power loss) the PC turns off not properly the files in use will be empty after reboot (sometimes 0 size, sometimes with a correct size but filled with only the corresponding amount of zeros).

 

I tried to simulate the situation by killing the application process from the task manager in windows which results in the same situation BUT only when i hit the exact moment when the file is being accessed - this is an understandable issue and can be of course handled by some backup mechanism. If i kill the process when the files is not in use - everything is fine.

 

But in the previous scenario the file gets corrupt even if the PC crash happens when the file is not being accessed. This simple vi illustrates it:corruptfile.png

 

I tried using Write to XML.vi and also MGI's Write Anything vis.

 

Does anybody have any idea what is happening there and how to handle this to prevent data loss?

 

Thank you!

 

0 Kudos
Message 1 of 7
(3,107 Views)

The only way I can think of to prevent this is instead of opening a file, passing file references, and close the file at exit, you would have to open, write, and close the file every single time you write to it.

 

Horribly inefficient, but safe.

========================
=== Engineer Ambiguously ===
========================
Message 2 of 7
(3,081 Views)

My guess is that data either is in the write cache when the PC is not shut down gracefully, or data is still in some queue and hasn't been written yet.  This is not a LabVIEW issue - it's a user issue.  The PC should always be shut down gracefully, even if this means attaching it to a UPS in case of power outage - especially if it is taking data!

 

To minimize (but not eliminate) this issue, make sure to explicitly write data to the file every so often and not just at the end of the test.  To help flush the write cache, you can close the file and re-open and append to it when you do the above exercise.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 7
(3,080 Views)

Oh good call billko, disabling Windows write caching would help too.

 

cashe.PNG 

========================
=== Engineer Ambiguously ===
========================
Message 4 of 7
(3,074 Views)

Thank you both for your replies.

Unfortunately your ideas didn't solve the issue..

 

...  instead of opening a file, passing file references, and close the file at exit, you would have to open, write, and close the file every single time you write to it.

Horribly inefficient, but safe.

 

This is what Write to XML.vi does internally so there is never a reference left unclosed - still the file becomes corrupt even after the reference was closed in the code. So this was actually my first thought - labview must be keeping the reference somewhere else too, which then is not properly closed at a crash.

 

 

... make sure to explicitly write data to the file every so often and not just at the end of the test.

 

This I'm also doing - i can see the file getting updated as the application runs with definitely a shorter delay than 500ms (referring to the example vi i posted where the loop's idle time of 500ms "seems" to be not enough to perform the write operation so that the file is written properly and the reference is closed). 

 

I'll be looking in more detail to how the process of writing to file happens at the OS level which i dont have much experience with..

 

 

 

 

 

0 Kudos
Message 5 of 7
(3,038 Views)

We also noted that none of these ideas are foolproof and that you really have to stop the action that leads to it.  You turn off the computer without a graceful shutdown enough times and you'll have a lot more to worry about than corrupt log files.

 

Still, the cache thing should help somewhat.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 7
(3,013 Views)
@ravyh wrote:

labview must be keeping the reference somewhere else too, which then is not properly closed at a crash.

 

this is rather unlikely.  If it were true, your test case would always reproduce.  It wouldn't reproduce only when the file was being written.

 

You're likely looking at it from a strange viewpoint.  What makes you so sure the file isn't being accessed when the PC crash happens?  Odds are that it is in fact being accessed based on the behavior and testing you've provided.  You'll want to focus on the crash more so than the VI, as others have stated.

0 Kudos
Message 7 of 7
(3,005 Views)