PDA

View Full Version : INI not writable



NewsArchive
06-12-2014, 01:56 AM
Hello Friedrich and all others,

today I ran into a problem with INI-files and same seemed to happen with the TPS also.

I generated an Installer with SB7, writing the EXEs and DLLs to C:\Program
Files\MyProject, the Data to COMMON_DOCUMENTS\Myproject and the INI to
PROGRAMDATA\MyProject.

The Installer requires being Admin, the actual user was logged-in as an admin,
too (of course!).

However, I had to learn that the INI did not save the changes from the program.
Then I tried to do some manual changes in the INI with no luck.

In the next step I opened the file properties to see its permissions. What I
found was the Administrator-Group had RW-permissions, but not the user (which
was an admin however). Changing the permissions enabled me to modify and save
the INI.

My next thought was, that C:\ProgramData\MyProject was actually one level too short.
So I enhanced the path (manually, not yet in my script and therefore not
compiled it, because I write from my livingroom, not from the office)
to C:\ProgramData\MyProject\MyProject and - tataaa - now I can modify and save
my INI with Notepad.

Just for clarification: it is a MUST to have the path to the INI 4 levels deep,
like C:\ProgramData\MyCompanyOrWhatever\MyProject, for the INI and assumingly
then for the data also? COMMON_DOCUMENTS\MyCompanyOrWhatever\Myproject

Finally, how about the binary files, EXE and DLL? C:\Program Files\MyProject
seems to be enough for now.

Thanks for enlightning.....

Regards,
Wolfgang Orth
www.odata.de

NewsArchive
06-12-2014, 03:12 AM
Wolfgang,

> I generated an Installer with SB7, writing the EXEs and DLLs to
> C:\Program Files\MyProject, the Data to COMMON_DOCUMENTS\Myproject
> and the INI to PROGRAMDATA\MyProject.
>
> The Installer requires being Admin, the actual user was logged-in
> as an admin, too (of course!).
>
> However, I had to learn that the INI did not save the changes from
> the program. Then I tried to do some manual changes in the INI
> with no luck.

Yes, this is expected and by Windows UAC design. The CommonApplicationData
directory serves as a common repository for application-specific data that
is used by *ALL* users. Non-elevated running applications do *NOT* have
permission to write to the that folder, because it does not belong to
specific users. If you really have to write to that special folder from a
non-elevated running app then you have to create your directory and set the
ACLs you need at install time.

BTW, being logged in as an Admin doesn't mean anything on UAC-aware
operating systems. By default, "asInvoker" manifested applications run
non-elevated!

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

--Helping You Build Better Installations
--SetupBuilder "point. click. ship"
--Create Windows 8 ready installations in minutes
--Official COMODO Code Signing and SSL Certificate Partner