INI file and Flush File.vi - Error 1

[Bruniii]

Hi,

in a larger application, sometime a small ini files get corrupted (a lot of NULL char and nothing else inside), and it looks like it happens when the computer restart and the application was running. I found this NI page: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001DwgyCAC&l=it-IT where the use of the "Flush file.vi" is suggested.

But a vary minimal and simple test like this one:

returns Error 1, always. And I really really cannot see what I'm supposed to do differently. It's problably something VERY stupid. Anyone here can help me?

 

Thank you,

Marco.

[Neil Pate]

I am a litle surprised LabVIEW lets you wire this together, as the reference coming out of the Open Config Data is not actually a file reference it is a queue reference.

So when you try and Flush you are passing in a Queue reference not a normal File reference, so this will not work.

 

Edited February 2 by Neil Pate

[Neil Pate]

Sorry I did not really offer any suggestions, I am not sure how to flush an ini file (never needed to). I normally close the file immediatley after modifying the contents.

[Bruniii]

Hi Neil,

thank you. In the main application the ini file is closed immediatly after the write, as you do. Still, three times in two years of running, after a restart of the pc (caused by a watchdog outside of my control) the ini file was corrupted, full of NULL char. Googling for some help I found the official NI support page that I linked that describes exactly these events and they are suggesting the use of the Flush File.

But, as you said, the refnum from the INI library doesn't look compatibile with the input refnum of the flush function...and I'm stuck

[Bruniii]

To be clear, I'm not at all sure that the Flush File will solve the corruption of the file in the main application; but NI believes that Flush File is the "main reccomandation" in this situation, hence I thought that adding this simple and small function would be super easy...

[Ronin7]

Maybe This is what they mean?

 

 

[Lior Bilia]

Is this a controlled restart of the PC or hard power cycle? Corrupted files can be the result of such power cycles, and your only solution in such case is to revert to a known good file that was not opened during the power cycle.

[Bruniii]

1 hour ago, Ronin7 said:

Maybe This is what they mean?

 

 

...Maybe?! It works, but will it helps? I guess I will have to wait another year, statistically...... but thank you!

1 hour ago, Lior Bilia said:

Is this a controlled restart of the PC or hard power cycle? Corrupted files can be the result of such power cycles, and your only solution in such case is to revert to a known good file that was not opened during the power cycle.

It's the hw watchdog of the industrial pc, but I have no control on on the kick/reset/timeout, so no way to do any operation before the restart.

[sam]

Your best option is to close the INI reference, and reopen it again right away. 

 The INI keys and sections are saved in some sorta queue when last I looked into it decades ago. So normal file IO functions are not going to work the ways you'd like.

 

 

[ShaunR]

The ini (or config file as NI calls them) are only written when the reference is closed.

You could put the flush in there but I don't think that's your problem.

I have seen this before and it is usually on a failing hard drive or one that is about to fail. NTFS has a sort of self healing which is insidious for small files (less than the cluster size) and this is the usual result of it "healing". Larger corruptions are more detectable with chkdsk.

Quote

NTFS continuously monitors and corrects transient corruption issues in the background without taking the volume offline. This feature is known as self-healing NTFS, which was introduced in Windows Server 2008.

(source)

I would take a look at the S.M.A.R.T (Self-Monitoring, Analysis, and Reporting Technology) information of your disk and pay particular attention to the write failures/errors.

Edited February 4 by ShaunR

[Rolf Kalbermatter]

On 2/2/2024 at 7:53 PM, Neil Pate said:

I am a litle surprised LabVIEW lets you wire this together, as the reference coming out of the Open Config Data is not actually a file reference it is a queue reference.

So when you try and Flush you are passing in a Queue reference not a normal File reference, so this will not work.

 

Neil, that queue reference is type casted to a LabVIEW datalog refnum. This is done to create a custom refnum "light". It works to prevent users from connecting this refnum to anything that is not an INI refnum ....... except file IO functions that also can deal with datalog refnums. The file IO function then tries to extract the underlaying file handle and that of course fails since the queue refnum does not have a file handle. Therefore you get the error 1.

If the OP really wants to hack a Flush into the library it would have to be added to the Config Close. But since this is the only time the whole file is even accessed with write access and there seems to be a little window of opportunity during the Write File function and the Close File function in there in which, when the power is yanked just in time, in the right way, the transfer to the disk is corrupted. The File Close should do a Flush too, although it may be somewhat delayed. How a Flush right before the Close would really help is more than doubtful.

I think Shaun's recommendation to check the S.M.A.R.T data for the drive in question may have some real merits here!

Edited February 4 by Rolf Kalbermatter

[Neil Pate]

12 hours ago, Rolf Kalbermatter said:

.... except file IO functions that also can deal with datalog refnums.

oops, sounds like a 30 year old bug! I think I remember the Config API was re-written sometime around LV 8.0? (or is my memory faulty) 

[Rolf Kalbermatter]

42 minutes ago, Neil Pate said:

oops, sounds like a 30 year old bug! I think I remember the Config API was re-written sometime around LV 8.0? (or is my memory faulty) 

About 30 years indeed. And bug is a strong word, it was a smart find back then to create your own refnums. While there would have been a better alternative around LabVIEW 7.1 (User refnums) there were several reasons not to use them. It was a new and not extremely well tested facility, it was really meant to incorporate binary shared library drivers with very little LabVIEW VIs and it would have broken the many Config File wrappers and application users that were creating a private copy of that “refnum” instead of using the Config File typedef.

[Neil Pate]

11 hours ago, Rolf Kalbermatter said:

And bug is a strong word...

Hmm, I think being able to wire that INI refnum into any file API and not having LabVIEW moan at you is definitely a bug.

[Rolf Kalbermatter]

14 hours ago, Neil Pate said:

Hmm, I think being able to wire that INI refnum into any file API and not having LabVIEW moan at you is definitely a bug.

It would have been a much more painful, and for most affected users even less trivial point to fix, if they replaced the original INI file fake refnum with a proper private user refnum. Any code that used a copy of that refnum in their own code somewhere would have simply broken. It was a judgment call: risk breaking a lot of existing code that improperly made a copy of that refnum or live with the limitations of the fake refnum. Not breaking existing code was always one of the top priorities in the LabVIEW development team, even if that existing code was born out of bad practice.

And it's not ANY file API. Only file functions that legitimately can operate on datalog file refnums. And they properly generate an error 1, since the refnum in question is indeed NOT a valid file refnum. There are other situations where you can logically connect data types to nodes but that node can't operate on that specific flavor of data type. LabVIEW is strongly typed but sometimes there is simply no easy way to make sure at compile time. As long as it produces proper error codes at runtime and doesn't crash, I consider it a valid trade off.

Edited February 6 by Rolf Kalbermatter

[Neil Pate]

Not sure I buy your logic, are you saying by keeping the refnum the old config API and the new one would be able to work together? ? Surely that would not have worked either. I cannot recall how the old API was implemented but I am guessing it was not the queue based one we have now (which I don't love either to be honest).

Anyway, let's not lose too much energy arguing over something this old 🙂

 

[Rolf Kalbermatter]

42 minutes ago, Neil Pate said:

Not sure I buy your logic, are you saying by keeping the refnum the old config API and the new one would be able to work together? ? Surely that would not have worked either. I cannot recall how the old API was implemented but I am guessing it was not the queue based one we have now (which I don't love either to be honest).

Anyway, let's not lose too much energy arguing over something this old 🙂

The old version was basically using the same config File refnum trick as the current one, only was the refnum a mask for something else than a queue, which did not exist back then. It was worse in the respect that it did read the ini file each time when writing anything to the configuration, so performance wise it was pretty sucky, and with a great possibility of concurrent access race conditions. As such the current implementation is definitely a huge improvement, but yes it caches all the configuration information in a queue which uses some extra memory.