Data Access Worldwide Knowledge Base
Article ID 2188 Article Title INFO: Protecting Against Unexpected Behaviors when Manipulating INI Files Article URL http://www.dataaccess.com/kbasepublic/kbprint.asp?ArticleID=2188 KBase Category VDF (GENERAL) Date Created 11/07/2005 Last Edit Date 11/22/2005
Article Text
The Visual DataFlex cIniFile class uses a number of messages to access a Windows INI file. Those are:
DeleteKey
DeleteSection
KeyExists
ReadSection
ReadSections
SectionExists
WriteString
All of these messages operate on an INI file that is identified by setting the psFileName property of an INI object. It is the developer's responsibility to make sure that they set psFileName. The default value of psFileName is "".
We recently determined that unintended, unexpected (and potentially damaging) behaviors can occur if the file name is not set prior to manipulating the INI file; sections of the Windows registry will be manipulated instead of the intended INI file. In cases where the developer's intent was to delete or edit sections of the INI file, sections of the registry would instead be deleted or edited.
It appears that this is expected Windows behavior. Our first step was to verify that the observed behavior was indeed happening at the Win32 API level. The cIniFile class uses GetPrivateProfileString() and WritePrivateProfileString(). We created a C program to verify the behavior of GetPrivateProfileString() when using a NULL filename. It behaves just like GetProfileString(); which is supposed to read win.ini. Since win.ini no longer exists per se, it's instead mapping to the registry. During testing we received the same information back using both GetPrivateProfileString() with a NULL file name and using GetProfileString(). We also verified that the information received corresponds to the information in the specified section in the registry containing the INF file mapping for win.ini.
We did not find any information specifically describing the intended behavior one way or another if you specify a NULL filename. We can only assume that a NULL filename is considered invalid, and other than that the behavior in such a case appears to be undefined. It is also possible that someone thought it was a good idea to map the NULL file name to win.ini. Or it's possible that it's just a side effect of the implementation (i.e. shared code or something), or that it's a side effect of the INI/registry file mapping.
Because of the undocumented behavior of the Win32 API, our packages create an object interface that makes it possible to lose track of the INI file name. A potential programming bug would be to forget to set psFileName and, if this happens, the resulting Windows behavior can result in unintended, unexpected and potentially catastrophic side-effects.
Therefore, we have changed the cIniFile package so that a NULL psFileName is never allowed. If you try to use a null psFileName, you get an error. This still allows developers to access the registry if they really want to (just set psFileName to win.ini or whatever) but it greatly reduces the chance that they will do this as part of a programming error. It was always our intention that a null filename was an error.
We have made this change as part of the Visual DataFlex 11.1 release. We are also publishing the updated cIniFile.pkg (attached to this KBase article) for use with prior revisions of Visual DataFlex.
We strongly recommend that all developers that use the cIniFile class to update to the new package or add their own protection against passing a NULL psFileName. Replace this package in your pkg directory, precompile all packages and recompile your application.
Web Links Related to this Article
File cIniFile.zip
URL=http://www.dataaccess.com/KBasePublic/Files/2188.cIniFile.zip
Email this Article
Email this Article to a Colleague
Send Feedback on this Article to Data Access Worldwide
Copyright ©2010 Data Access Corporation. All rights reserved.
The information provided in the Data Access Technical Knowledge Base is provided "as is" without warranty of any kind. Data Access Corporation disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Data Access Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Data Access Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.