Corrupted INI file

[JB]

Hi,

For several years, various versions of Windows and LabVIEW, occasionally, configuration files get corrupted in our applications.

These files are generated with NI's Configuration File VIs. A very simple, but real example which generated a corrupted file.

Opening the file with an editor such as Notepad, you might think at first glance that there are two blank lines at the start of the file.

But Notepad++ reveals something else for the first line : many NUL characters (82 in below example) followed by a CRLF

In one case, there were spaces instead of NUL.

Have any of you encountered this problem?

Many thanks in advance for any help

[billko]

I have no idea why that would happen especially since it's intermittent.  If I had to guess, it would be that the file was being manipulated outside of LabVIEW somehow.

[JB]

At least, typing NUL with a keyboard would be quite difficult. 🤔

[billko]

LOL, too funny - and true.

[altenbach]

Is the "corruption" benign, i.e. does everything still work, even if these nulls are there?

Also note that the configuration file tools are all plain VIs with (mostly?) accessible diagrams, so you can easily tell if there is anything fishy that would cause this.

[Yamaeda]

That's never happened to me. I would expect that there's some corruption in the data that's written, unless there's some other process affecting the file as Altenbach mentions.

Probe and double check that you're not writing Section with bad characters, e.g.

[JB]

Thank you for your answers.

@billko : Even if they remain very rare, the cases are sufficiently widespread in our production facilities to exclude human modification. NUL also rule out this probability.

@Altenbach : Yes, the example shown does not pose any problem and goes completely unnoticed. But, I suppose that this is the starting point for rare cases (2-3/year, about 150 LV applications run on our assembly lines) with the disappearance of the useful data.

@Yameada : All of our attempts to reproduce the bug were unsuccessful. This very rare bug has appeared on several applications, versions of Windows and LV. The types of data written/read obviously vary depending on the application. The only common point seems to be the use of NI's library... and our usage of it.

I cannot rule out that we are passing on an inappropriate way of doing things from application to application. But this library is very easy to use and the options are not numerous. To this day, I do not know anything about the origin of this corruption. Could it even come from reading? Could this occur if some other process (eg file indexing by OS) accesses this file?

If someone could find a file with the same corruption, it would help guide our research. If anyone (from NI) can exclude the library from writing NUL, that would be very helpful as well. If so, obviously also under what circumstances it does so.

Wishing you a pleasant weekend

[billko]

Sorry, I didn't mean to make it sound trivial because even if it was only one byte that was messing up your ini file, it's still going to cause major headaches.

[drjdpowell]

You could just copy either the open or close VIs and modify it to drop NULs.  Then use this new version in your apps.  Assuming the issue, whatever it is, is just adding NULs, rather than messing up something else.

[drjdpowell]

Do any of your multiple apps share common config files?  Possible loss of data can happen due to read-write race conditions.  If I were asked how to improve that NI library, fixing that hole would be my first suggestion.