Inireadsectionnames Broken On < Winxp

[james3mg]

I script which basically acts as a database (a rather limited one, by which functions I put into it ). It stores all its data in several .ini files, but one is the 'main' file - it's called "jobinfo.ini". This file has almost 300 sections in it currently. When the script loads, it stores all the section names and a few of the keys in each section into a 3-dimensional array. It does this by first reading the section names in the .ini file and storing them in an array. Then, using loop functions, I populate the rest of the dimensions by reading specific keys under each section. XP and above run this script fine.

My problem is with ME and below - when it gets to the IniReadSectionNames(), it throws an error. I tried replacing that .ini file with another one that only had four sections, and it ran fine. Is there some limit that I can't find in the documentation that would limit the size of .ini file that WinME can read by file size, number of lines, or number of sections? I can have it FileRead() the file fine and confirm that the first line contains a section name (check StringLeft and StringRight for [ and ] ), so I know it's accessing the file correctly - it just can't store all the section names in an array, apparently - at least not using IniReadSectionNames().

Has anyone else hit this wall before or have any idea what the limit is that is breaking my script below WinXP?

Thanks

[SmOke_N]

I script which basically acts as a database (a rather limited one, by which functions I put into it ). It stores all its data in several .ini files, but one is the 'main' file - it's called "jobinfo.ini". This file has almost 300 sections in it currently. When the script loads, it stores all the section names and a few of the keys in each section into a 3-dimensional array. It does this by first reading the section names in the .ini file and storing them in an array. Then, using loop functions, I populate the rest of the dimensions by reading specific keys under each section. XP and above run this script fine.

My problem is with ME and below - when it gets to the IniReadSectionNames(), it throws an error. I tried replacing that .ini file with another one that only had four sections, and it ran fine. Is there some limit that I can't find in the documentation that would limit the size of .ini file that WinME can read by file size, number of lines, or number of sections? I can have it FileRead() the file fine and confirm that the first line contains a section name (check StringLeft and StringRight for [ and ] ), so I know it's accessing the file correctly - it just can't store all the section names in an array, apparently - at least not using IniReadSectionNames().

Has anyone else hit this wall before or have any idea what the limit is that is breaking my script below WinXP?

Thanks

It used to be (don't know if it is still like that) that an Ini could only be 64kb's.

[james3mg]

It used to be (don't know if it is still like that) that an Ini could only be 64kb's.

That seems to be the wall I'm hitting - thanks! I reduced the file size to 64.4KB, and it still didn't work, but by removing one more section, I got it to 63.8KB and it started working. So I assume that's a limitation of the OS, correct?

So XP doesn't appear to have that 64KB limitation...does anyone know if there is an upper limit of .ini file sizes under XP and higher?

Thanks

[james3mg]

I haven't found a definite answer to XP's limit of .ini files, but I wrote a script to recursively write to an .ini file and test it at every step - it's up to more than 110MB so far: over 5100 unique sections each containing 25 keys, and it's still reading it perfectly, so that's powerful enough for me! (though due to the sheer size of the file, it takes about 30 seconds on my machine to do a full ReadSectionNames() )

(just in case anyone else has this question too)

Have a good'n

[Valik]

You mean the function works on files larger than 64KB (on XP)? Are you sure? I thought I had hard-coded the buffer size to 64KB it shouldn't even be reading more data than that.

Edit: If I didn't restrict the buffer size on IniReadSectionNames(), I know it's restricted with other Ini functions so even if you can create a massive file, you still won't be able to read/write to all of the data in it using AutoIt's built-in Ini functions.

Edited May 9, 2006 by Valik

[james3mg]

You mean the function works on files larger than 64KB (on XP)? Are you sure? I thought I had hard-coded the buffer size to 64KB it shouldn't even be reading more data than that.

Edit: If I didn't restrict the buffer size on IniReadSectionNames(), I know it's restricted with other Ini functions so even if you can create a massive file, you still won't be able to read/write to all of the data in it using AutoIt's built-in Ini functions.

Valik,

That scares me, because it means that there is an intended limit that, if enforced, would render my script (which I've put a bit of developing time into) useless. It's working great right now on XP and Server 2003, so I hope it doesn't break with future releases...

I'm going to PM you a .zip file containing my 'database' program so you can see how it works, and as proof that it's writing/reading to a file currently at over 100KB. I'm not going to post the code on the forums until

(1) it's done...there's still some functions I haven't put into the script

(2) I've scrubbed out the personal information of my company's clients from the ini file.

So please look at it for whatever you need to satisfy your mind of its functionality but don't let it get any further than your desktop, please ;-)

[Valik]

I strongly encourage you to re-think your design.

First, I just checked the buffer sizes used internally and it's 32KB for IniReadSectionNames(). That means if you ever have more than 32KB of section name data or you ever try to use IniReadSection(), your script will only get the first 32KB of data.

IniRead()/IniWrite() work a little differently, they are just thin wrappers around underlying Windows API calls which is why they work. They will not work on earlier versions of Windows.

Also, I doubt IniReadSectionNames() will work on earlier versions of Windows, either.

If you want to use an INI formatted file, I suggest you write your own versions using AutoIt's File* functions so you can circumvent any size limitations. Continuing to use the INI functions in an unsupported way is setting yourself up for problems later on including a high potential for data-loss.

PS, I didn't look at the file you sent to me. I just took a look at the source to see how the functions work.

[james3mg]

I strongly encourage you to re-think your design.

...

Hmmm...well that hurts... I sure appreciate the heads-up about the risk though!!

I'm trying to figure out how to make my own quasi-ini parser functions -

{typing, thinking, experimenting, deleting}

I started to ask how you'd go about rewriting these functions because I've thought about doing this before, but I was always stumped by duplicating IniWrite(). But digging a little more, I just found _FileWriteToLine, and that seems like it'll work. I think (unless someone suggests a better way) I'll set up my version of the IniRead() function to read the whole .ini file line by line, storing in an array the contents and line number whenever it finds a line starting with a left bracket and ending with a right bracket...then for reading a key, I can do

while $i = [section line number] to [next section line number]

then use StringRight to return the text to the right of the = sign. I just wonder how much slower all this searching is going to be than the built-in windows .ini functions. Oh well, it's gotta be done, if stability's at stake. I'll have to look at how _fileWriteToLine() is written to make sure it's not using any "dangerous" functions stability-wise like the .ini ones. Maybe I can rewrite it into my script so I don't have to include the whole file.au3.

Thanks for your feedback - I REALLY appreciate knowing about this before it crashes with our data (fortunately I do LOTS of automatic backups and I could roll back and write a script to strip the data out into a .csv format or something if that ever happened). Maybe if I do a good enough job I'll throw a new UDF out there with the new .ini functions. This is gonna suck...