windowswinapicachingflushini

Does Windows NT cache or flush INI-file writings?

I am updating a rather old application. It used INI file accesses all around the code, creating and freeing INI-accessing class instances here and there.

I want to centralize this to several singleton instances, one per used file. So we'd get rid of instances creating/freeing copy-pasted snippets everywhere and would have freedom to completely replace those classes would be decision to switch from INI to other settings back-end.

Should one call WritePrivateProfileString(NULL, NULL, NULL...) to apply the changes? Assume that:

  1. the access goes directly to real INI-files, not to registry mapped ones.
  2. OS is of NT family (maybe rarely Win2000, most probably WinXP and later). Win9x/ReactOS/WinE/Odin/etc are not cared for.

So, should we flush the ini-written settings now explicitly or not ?

NT does not cache Registry key writes, do no need to regFlushKey for those. But what about the plain INI files?

MSDN page about WritePrivateProfileString only describes flushing technique wrt Win9x and NT File-to-Reg mappings. It is silent about real INI files.

UPD. re-checked, as of 2025 MSDN still lacks information here.

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-writeprivateprofilestringa

Solution

  • The documentation contradicts itself (my bold):

    The system keeps a cached version of the most recent registry file mapping to improve performance. If all parameters are NULL, the function flushes the cache. While the system is editing the cached version of the file, processes that edit the file itself will use the original file until the cache has been cleared.

    Is Windows caching the mapping or a file (what file)? But the comment in the sample code makes it clear:

    // Force the system to read the mapping into shared memory 
// so that future invocations of the application will see it 
// without the user having to reboot the system

    It is the registry file mapping that is cached. If you alter the mapping in the registry then you need to tell Windows to refresh its cache.

    This is also consistent with usage of the API in Windows 3.1, where you didn't need to flush anything. It's unlikely that Windows would fundamentally change the usage of the API.

    To double-check, I called WritePrivateProfileString while running Process Monitor. As expected, Windows opens the INI file, updates it and closes it again.

    No flushing required.