Corrupted INI file

[billko]

---

@JB wrote:

---

@billko  a écrit :

Are some of the key/value pairs created programmatically?  Maybe some weird chain of events leads to some error condition that leads to the creation of a bad key name and/or value?

---

Keys are obviously generated if they do not exist. But this is the case only when running the application for the very first time. Thereafter, only the values can change.

As the example from my first post shows, keys and data remain intact. At least initially.

I've wondered if an error while updating values, between opening the file and closing it, could cause these unexpected characters.

---

It's hard to say, as I will be the first to admit wild speculation on my part.

[Frozen]

I once had something like that happen.... when I got an INI file from China. At the time, I chalked it up to non-English OS being installed. Something to keep in mind since LV is not very unicode safe. Does your file name in your example have non-ascii characters?

(NOTE: I maybe using the terms unicode and ASCII incorrectly since the whole encoding vs char sets I find very confusing)

[JB]

---

@Frozen  a écrit :

I once had something like that happen.... when I got an INI file from China. At the time, I chalked it up to non-English OS being installed. Something to keep in mind since LV is not very unicode safe. Does your file name in your example have non-ascii characters?

(NOTE: I maybe using the terms unicode and ASCII incorrectly since the whole encoding vs char sets I find very confusing)

---

Thank you for this idea.

No, this is not the case.

[drjdpowell]

I usually use JSON rather than INI for config files, and l have encountered the problem of some text editors "helpfully" adding Byte Order Marks to indicate UTF8 encoding.  The BOM bytes are not displayed in the editor so you don't realize they are there.  However, I don't think such BOM could cause your problems.

[JÞB]

---

@JB wrote:

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

---

I would like to get a bit farther down the research trail here.

A least you should be showing display style on those string constants!  

I also wonder about any silly problems with localization such as a potential malformed import or export string.

Are there any user preferences in the ini file? ( thinking 1 rare preference may be corrupatable)  

The current API's refnum data is actually a reference to an unnamed queue having a specific datatype so deeply buried as to be "almost" incorruptible from LabVIEW ( although I imagine that it could be done with a couple of interesting modifications to the API on a development machine)  so that begs the question about an IDE corrupt on a single developers station and a look at how you deploy to 150 test stations and test station configuration management. 

I don't envy you!   Except for the fact that the affected stations DO THROW a valid error you would be in really big trouble. 

In other words,  you have a bug! Right now about all you can do is note it and track it down from investigation into each new occurrence.