INIWrite File Locking

[Shadeclan]

Does the INIWrite function lock the target INI file?

[jchd]

I suppose it's locked by the OS against concurrent writes, but not against concurrent read.

Concurrent acces to application data storage is better done via registry for low-volume data or database (e.g. SQLite) for significant volume data.

[orbs]

9 minutes ago, jchd said:

I suppose it's locked by the OS against concurrent writes, but not against concurrent read.

Sadly, that is not so. There is no locking whatsoever. Search the "Example Scripts" forum for FileLock() or "cooperative semaphore".

[Shadeclan]

Thanks.  Any known results of collisions when using INIWrite?

[BrewManNH]

If two people are writing to the file at the same time to the same section and key you'll have no way of knowing which one gets saved.

[Shadeclan]

Not an issue.  Just want to make sure that the data being written is not corrupted in some way.

[jchd]

Please expose more of your actual issue since it's unclear which situation you have in mind. It all depends on the concurrency you expect and which corruption you want to avoid.

[Shadeclan]

I'm setting up a situation in which multiple people are writing to a single INI file.  I have a simple strategy in mind that will prevent most collisions and can handle overwrites but in the rare instance that a collision happens, I would like to know if data corruption will occur.

Edited April 20, 2016 by Shadeclan

[jchd]

In your use case, yes you need file locking, else this simple concurrency situation would result in unexpected result:

Process A reads the file
Process B reads the file
Process A modifies its copy in RAM and rewrites the file
Process B modifies its copy in RAM and rewrites the file

Changes made by A are lost yet no error occured. Hence you need some kind of file locking, providing ACID properties.
 

[orbs]

14 hours ago, Shadeclan said:

I'm setting up a situation in which multiple people are writing to a single INI file.  I have a simple strategy in mind that will prevent most collisions and can handle overwrites but in the rare instance that a collision happens, I would like to know if data corruption will occur.

Hope you are not planning too large amount of data accumulating; ini will fail you. Updating a value in ini file - as opposed to appending a value at end - causes a rewrite of the entire file, so you may be in for a lot of trouble. You should really put some consideration as to the best data store to use. 

Regardless, why limit yourself to preventing "most" collisions, when you can prevent all of them? I can heartily recommend the "cooperative semaphore" UDF, it's very easy to use. At times I had near 40 scripts writing to a file almost simultaneously with no issues. I never bothered with corruption, because that could only be caused by hardware issues, and would be easily mended if occured; but you can ease your mind by reading the data just entered for validation.

[JohnOne]

If you insist on using an ini file,  you should consider using a multi client server to handle the writes, consecutively.

[Skysnake]

Multiple users reading/writing seems to suggest database functionality?  

I hate it when people reply saying "you shouldn't be using that, use this" but I find myself there right now.  why on earth would you want multiple users to write to something as limited as an INI file?  INI files are incredibly simple and powerful, certainly not designed for a multi user read/write environment.

Good luck

[Shadeclan]

The INI file format lent itself nicely to my app idea, which is why I'm using it.  The file to which multiple users are writing - they only do it one time and the structure is very small and simple.  I just wanted to make sure that there was no corruption of data if multiple instances of the app were writing to the same file.

I created about 12 copies of a test EXE that wrote different strings of letters to a key value in a loop and executed them at the same time, sometimes by random clicking and sometimes by selecting all and hitting the enter key.  From my stress testing, It appears that the key value will not be corrupted by multiple user access.  Probably should have done that first but I thought that somebody would have already tried this.  My simple locking scheme can handle overwrites without issues, so looks like I'm golden.

Thank you for all your suggestions - you all have been a great help.  If I write anything more complex, I will certainly look into UDF.

[guinness]

On 21/04/2016 at 4:14 PM, Skysnake said:

I hate it when people reply saying "you shouldn't be using that, use this" but I find myself there right now

Yeah, I hate it too when people tell me the right way of doing things.