Reported 4.42 32-bit: Your INI file is read only! (unless you Run as Administrator)

[jbruchon]

Windows 7 Pro x64. Removed all Irfanview versions, program file folders, and configuration files prior to installing 4.42 32-bit. When I try to open Preferences or try to use Batch Processing, I am warned that my INI file "C:\Program Files (x86)\Irfanview\i_view32.ini" is read-only. I have confirmed that this INI file exists and the contents seem to be a "redirect" to %AppData%\IrfanView which also contains an i_view32.ini file with actual settings. In this state I cannot change preferences, even if I grant my account "Full Control" over the INI file in the program directory.

When "Run as Administrator" or with Compatibility Mode for XP SP3 (which runs as administrator also) it works as expected. This has been a problem for a few versions leading up to 4.42 also, and I think I recall it happening on the x64 version too (but don't have that installed due to previous Unicode and UNC path issues that are deal-breakers for me).

I suspect this is due to UAC virtualization: http://www.sevenforums.com/news/1942...direction.html

I assume this is a bug where IrfanView doesn't follow the "redirection" in the program directory INI properly or it's trying to open it for read-write access and failing (as it should with UAC enabled).

[jbruchon]

I have just discovered that I had a file %LocalAppData%\VirtualStore\Program Files (x86)\Irfanview\i_view32.ini that was causing this to happen; when deleted, the problem goes away. I still think this counts as a bug in the software, but the obvious workaround is to delete the virtualized INI file.

[Bhikkhu Pesala]

I don't think there is any bug here. I think you used the wrong installation option.

[jbruchon]

I don't think there is any bug here. I think you used the wrong installation option.

I never use the wrong installation option; the one you highlighted is both the default and the one I have always used. I don't know why there was a virtualized INI file but it is definitely a bug if such a file existing causes the user to be locked out of changing all configuration options in the program. If the location for the INI file was stored in the registry instead of yet another an INI file, that would easily and permanently fix the problem. If avoiding the registry at all costs is important, the program could at least detect and erase the INI under VirtualStore automatically.

[Jacal]

On my computer, ini file in "virtualstore" only contains INI_Folder path and registration information. No problems here.

[jbruchon]

I remade the VirtualStore INI to test the cause. If I copy the "redirecting" INI from the Program Files directory it always works OK. If I copy the one from %AppData%\Irfanview (the one with the actual settings) it also works OK. When I make that file read-only, however, it triggers the failure. I'm not sure how or why a read-only non-redirect INI ended up there.

I still believe that the proper behavior would be to store the INI location selected during setup in a registry entry and have the program load the INI that way, rather than the INI redirection system currently employed. If I select the user profile INI during setup, the last thing I would expect is for it to have a problem because an application folder INI exists anywhere. It also reports the wrong path for the INI that is causing the failure; had I not known about UAC virtualization, I'd have been at a total loss. This persisted across uninstalls and reinstalls of the program too.

[Mij]

It also reports the wrong path for the INI that is causing the failure; had I not known about UAC virtualization, I'd have been at a total loss. This persisted across uninstalls and reinstalls of the program too.

I think if you had not known about UAC virtualization you would not have wasted your time playing about with it. I can hardly believe that I was 9 years younger when we were first arguing about it in Vista. It was introduced in Vista to deal with legacy programs (like Irfanview) that kept data such as user configuration files (i_view32.ini) in the same folder as the executable program file (i_view32.exe). In Widows 7 the Virtual Store folder is just somewhere to keep a legacy of a legacy.

Irfan Skiljan took the decision many years ago to keep an "ini" file in the program folder and not to put all the settings from it into the registry. Many of us think he was right to do so and are pleased that he did. The way he chose to avoid the problem of being unable to write to an "ini" file in the program folder was the Redirect. In that copy of the ini file should be the entry

[Others]
INI_Folder=%APPDATA%\IrfanView

When Irfanview sees that entry it will read and write instead to a file in the Current User's Application Data folder (usually C:\Users\[User Name]\AppData\Roaming\Irfanview).
If you have a an "ini" file in your Application Data folder that is read only, it was not created by Irfanview. It is an old file from somewhere. I would delete it completely and let Irfanview create a new one. I would certainly delete any "ini" file in a Virtual store folder and, if I found it being created again, look closely at what is in the i_view32.ini file in the same folder as i_view32.exe. It must contain that section header [Others] and have the redirect line, exactly as shown in the quote, below it.

Files in your Application Data folder are not modified during installation of a new version of Irfanview. Your old settings are kept as they were. Any changes that happen are made when the program is running.

[jbruchon]

Normal users will not know to fish around in VirtualStore. Our collective technical knowledge doesn't help less savvy end users that run into this, and because it persists across uninstalls it means IrfanView ceases to be configurable on that user account "forever" from the user's point of view. Regardless of how the virtualized INI file came into existence, IrfanView needs to issue a correct error message. According to your post in that thread, "It is important that old IrfanView INI files lurking there should be cleared out." Why doesn't the installer or the program give a warning if a virtualized INI exists?

I do not wish to discuss the merits of INI files vs. registry data; I did not intend to wander that far out of scope and I understand that there are important benefits to using INI files. The point is that we need to see a correct path for the read-only INI that's locking the IrfanView configuration down when the "INI file is read-only" error appears.

[Mij]

Normal users will not know to fish around in VirtualStore........
According to your post in that thread, "It is important that old IrfanView INI files lurking there should be cleared out." Why doesn't the installer or the program give a warning if a virtualized INI exists?

That quote dates from 2009 when a lot of Irfanview users with Vista still had old INI files left in a VirtualStore folder. When Vista first launched that was where the INI file always ended up, if the EXE file was in Program Files folder. I had spent much time in the previous year telling Normal users how to fish around in Virtual store to find it.
IMHO the redirect INI when introduced provided a good solution to the problem and has done ever since. I recommended to then get rid of the INI file in VirtualStore to avoid the confusion many users had about which INI file they were actually using. If it never came back it showed that the redirect INI was working as it should too.

After that massive debate in the 2009 thread that my quoted post comes from, I do not recall anyone having problems with VirtualStore again until now. Having just re-read the rest of that old thread, I discovered why some of your arguments seemed rather familiar, jbruchen.