Managing an ini file from a plugin

[mnsandler]

I've been using the hs.saveinisetting and hs.getinisetting methods however when hs3 crashes or the server crashes, my plugin ini files get corrupt.

I never had this issue with HS2.

So, I'm looking for an alternative to managing the ini file myself via the plugin.

Any suggestions for managing an ini file within the plugin?

What's the best approach?
1. opening and closing the file with each read and write
2. opening the file at the plugin startup, periodically writing, and closing at shutdown
3. something else

[happnatious1]

I thought about storing configuration data a lot while I was building my monoprice amp plugin. I ended up storing everything in ped because it made distribution easier. Instead of having to give people the exe file and have them copy an ini text file somewhere I just serealized my data into an object and stored it in the device itself. I believe the plug-in information from homeseer recommends this method.
The downside is that you can't have someone just give you their ini file to see if there's problems with their settings or to make modifications.
I honestly don't know if there is a performance issue with large ini files between opening an ini file for reading and deserializing data from ped.
I certainly would close the file immediately after writing to it because leaving an open file handle seems like a recipe for problems.
Good discussion, hopefully someone with more knowledge than me will chime in.

[dcorsus]

Hi Mark, do you write that much to the ini file? Must admit that I have a lot of information in my ini file but never had a complaint that the file got corrupted. I read quite occasionally, write less frequent. Could the corruption come from something else? Do you add/delete entries or sections perhaps?
Just a thought
Dirk

[mnsandler]

for my insteon plugin, I save comm stats every 5 minutes to the ini.

the problem/corruption only occurs when the hs server crashes. I can't figure out if this is a disk issue (like write cache) or hs3 not writing the ini to disk frequently enough.

I've never received a report that the ini file got corrupt during normal operations.

[dcorsus]

for my insteon plugin, I save comm stats every 5 minutes to the ini.

the problem/corruption only occurs when the hs server crashes. I can't figure out if this is a disk issue (like write cache) or hs3 not writing the ini to disk frequently enough.

I've never received a report that the ini file got corrupt during normal operations.

I see ... maybe set up a little experiment? Write a ton for say a day see if it corrupts without a server crash or see if it crashes the server?

[rmasonjr]

I read frequently from my INI file, but only save when the user changes some config value. If I had to do it all over again, I would create a Config object that loads all the values on startup and read from a built in collection instead of getinisetting over and over.

Not sure what the magic solution is for writing though.

Like happnatious1, I use PED quite a bit to store plugin specific data for my devices. It is very handy and works very well.

[mnsandler]

I do use the PED for a few things in hs3, but I stuck with the ini to make the transition from hs2 to hs3 a lot easier on the users. The plugin just reads the ini and recreates the necessary hs devices. If a user accidently deletes a plugin device, the user can get the plugin to recreate (except for ref id) very easily.

who knows if PED will be part of HS4. the ini is HST independent which I like.

[happnatious1]

I would think that creating an object, weather using an ini file or ped, and populating it with information just on plugin Startup or when necessary, would do a lot to speed up your plug-in. reading and writing to disc is a slow process.

[mrhappy]

I'm trying to move away from them and now pretty much only store login details in them save for another couple of bits of information such as debug settings. I have reservations as to the read/write cycles of SD card based systems and whilst you can do everything to minimise read/writes/opens/closes you could end up with a user running a poorly designed script that caused repeated file transactions.

As there is no method in .net for Ini file handling I imagine that (considering the requirement for Mono) that Rich has probably written his own method? Perhaps might be the odd bug keeping files open?

[mnsandler]

As there is no method in .net for Ini file handling I imagine that (considering the requirement for Mono) that Rich has probably written his own method? Perhaps might be the odd bug keeping files open?

Rich has written his own ini methods and that is my fundamental problem. HS3 is somehow corrupting my ini file if hs3 or the hs server crashes.

I found another ini library from codeproject.com that I may use and see how it goes. I plan to open/read into object/close the ini file when the plugin first starts up, then just update the object and save the ini file as required. At least this way, if the ini gets corrupt I know its my code and I might be able to resolve it.

[Mountainman]

If the problem is that the ini file is open for writing when HomeSeer crashes, what if you do this when you want to write to your file:

1) Create a new ini file with a different filename and the new information.
2) Close the file.
3) Open the file, read it, and verify it is correct.
4) Close the file.
5) Delete the current working ini file.
6) Rename the new ini file with the working ini filename.

If the system crashes between steps 5 and 6, you could revert to a backup ini file the next time HomeSeer is started so the plug-in doesn't come up totally dead.

All of these steps are somewhat re-inventing what a database is suppose to do for you it seems. Anyway, just an idea.

[mnsandler]

I wanted to close this out with my current solution:

First i'm using the iniFile class from codeproject.org

at the first read or write to the ini file, i load the ini file into an object.

in order to minimize the frequency of writing to the ini file, I use an AutoResetEvent object. With each write to the ini object, i set an AutoResetEvent object. I capture this event in another thread. See the code fragment below. if I'm updating the ini object very rapidly, the ini file isn't updated until there is a small delay/timeout (3 secs in my case)

During the Save to disk, I also implemented something similar to what MountainMan suggested above. I write the updated ini object to an ini.tmp file. then open/read that file, and verify the number of sections matches the current ini object. If there is a match, then i copy the ini.tmp file to the ini file.

within the ini read and write to disk routines, i use a ReaderWriterLock object to make sure the file is only used for one transaction at a time.

I hope this makes sense to anyone who might need this.

Do While Not gShutdown
	TimedOut = Not AutoSave.WaitOne(SAVE_TIMEOUT * 1000) ' auto exit after x msecs

	If TimedOut Then
		If Not Saved Then
			Saved = SaveINI(INI_NAME) ' should be True for a successful save
		End If
	Else
		Saved = False ' a Set was received which means a change was made; so we need to save on the next timeout
	End If
Loop

[Mountainman]

That sounds good. Let us know how robust this turns out to be after it gets used for a while in the real world.