>>>>To put it in simple terms. %programdata% is read only for users for decades.
>>>>It is stated that it does not require elevated privileges - what only means a admin can write to it without extra dialouge.
>>>>You can use your installer to create a folder with permissions if you realy need this.
>>>>
>>>>The file should end up in some roaming folder. I'm no expert in this folders (It's Redmond idiotic - one can write or not). But simply give it a unique name and search your whole comp for the file.
>>>>There should be some environment variable or a reg key that gives you the path to the roaming (don't trust hard coded here). Google will be your friend.
>>>
>>>Prior to Windows 10 we're been using ProgramData without any issues. The program still works fine and writes to ProgramData when we run it as a program (at least in my earlier tries). But it doesn't work anymore if testing from VFP directly when not running VFP as Admin. I raised that question yesterday to my colleagues and one of them said he is running VFP as Admin. Well, it will work as a workaround for me, but perhaps we would need to figure out a different folder for our apps log files (and .ini files).
>>
>>I have access XP, Win 8.1 and a Win 7. %ProgramData% is RO to user in 7 and 8.1. Admins have RW access.
>>My XP does not know about %ProgramData%. What, in that, was prior to Win 10, then? Vista?
>>
>>The simple solution is to install a folder to %ProgramData% with apropriate rights, or to choose a location where public RW is possible.
>>
>>I guess you will be able to get the recent permissions for a running app via API?
>>
>>The problem to not run anything as Admin is boring. If you would have done the right thing the days of Win95, you wouldn't have a problem right now.
>
>I haven't yet tried to change folder permissions programmaticaly from VFP. However, when I try to change them manually from the Properties/Advanced dialog I'm getting a warning about needing Admin permissions to change. I then click Continue on that dialog, open the properties again to find out that the folder's files are still readonly.
>
>How this dialog was created originally I'm not certain - if I created it manually myself first or was it created when I was installing our apps.
>
>I used (and still have) Windows 7 on my older laptop where I didn't have the problem.

I'm probably way off base on this, but shouldn't you be looking at the Security page rather than the General page? If I'm not mistaken, the attributes that show up on the General page are those that are connected to the ATTRIB command, which is completely different from access rights information.