I am trying to write Memo text to a .txt file in Delphi XE3, in Windows 8, but for some reason when I run the program in the IDE it works (the temp .exe is on my D: drive) but when I copy my program to C:\Myprogram.exe it gives error "Access denied" so i cant write anywhere on C:\
I already tried making a manifest and that did not work.
P.S.: I don't want to run my program as an administrator and when I do run as admin it works.
If you're not an administrator, you cannot write in certain places. That is to protect you (or your users) and it's a rule you cannot circumvent without disabling UAC, which you should't rely on (if it's possible at all in Windows 8).
Pick a location you can write to, for instance a Documents folder or another special folder for storing application data.
Related
I am a vb6 coder, and facing problem with a Windows 7 UAC issue.
Limited User:
When I run my installer, it asks for an admin account password, I enter and it installed it correctly.
My app writes dates to a common application data folder so that all users can access the file/data.
In Windows 7, the path is :
C:\ProgramData\<CompanyName>\<AppName/Title>\Config.ini
as my installer runs with admin rights, it creates those subfolders correctly.
But, when the app runs from a limited user account. It failed to write at that location (it actually writes to virtual path).
But, I want to write to that exact file.
However, I have researched enough and every where it is told to write in CommonAppData folder.
But it still fails.
please some one help me out.
I use SHGetSpecialFolderLocation API call to get the folder location and I use folder id 35.
below is the sample code for the path:
strAPPPath = fGetSpecialfolder(35) & "\" & App.CompanyName & "\" & Trim(App.Title)
I wasn't trying to suggest that your installer was the problem, I wanted to know what capabilities that your installer had. As I said I am running a post install Custom Action, in it I make my directory, set the permissions on it and copy my config files to it. It looks like your Installer has the ability to do Interactive and Shell Operations, but since I am not familiar with it I will refrain trying to give you an example. The command that I use to set the permissions of the Directory is the dos calcs command. And the command line that I use is.
cacls "%ALLUSERSPROFILE%\**<Your Directorys here>**" /E /P BUILTIN\Users:F
I was hoping someone would jump in and give an alternative way to do this, since I would like to loose the bat file.
You could try using procmon from www.sysinternals.com (which redirects to MS Technet) and find the disk access that your application is making to access the data folder.
It will give you a better error message that should point you in the right direction, such as permissions.
I have created a small vb6 application which edits the registry in HKLM hive. It makes use of function RegSetValueEx. But when run the exe file in windows 7 and windows 8 pc it does not edit the registry even if run it in administrator user.
In windows XP it works fine.If i run same application as "run as administrator"(by right clicking exe and then run as) in windows 7 and 8 then it works properly.I think the windows 7 and 8 id designed to work like this only. But is there any method i can edit it without running as administrator? Or is there any code in vb6 which does the same.
Here is my small code
Important:
When checking the code create exe and then run the exe and click on button(HKEY_LOCAL_MACHINE\SOFTWARE\Demo registry gets added in wow32 node because vb6 is a 32 bit appliaction).Running the code directly by opening code allows the registry to change.But creating the exe and then running it gives the problem which is the real time scenario in any application.
Microsoft has been warning developers since Windows 2000 that access to the HKLM branch of the registry should not be performed as normal user, as it will sooner or later be restricted to administrators. They also said you should not write to Program Files.
They didn't enforce that rule until Windows Vista, so nobody felt the need to change anything.
Now you have it: don't write to HKLM as normal user - it doesn't work. Don't write your settings to Program Files. It doesn't work.
Application run by the normal user may write their data to user folders and user hives in the registry, nowhere else.
If your application's sole purpose is to write to that value in the HKLM hive then you will need to add a "requiresAdministrator` manifest to the executable, causing Windows to prompt the user for admin access every time it's run.
If this is a small part of a larger project, then you should use COM elevation or just run a small stub executable with the manifest above, allowing windows to only prompt when it's required.
If your application doesn't require admin access at all then you should stop it trying to write to admin restricted locations, and instead use the user's own HKCU hive.
i have made a game and it's self installer after the game is installed it runs only if it is installed on e drive or d drive not in the c drive that has my os
it says access denied
somebody told me that it needs permissions by making registry changes
is it so?
i know how make the changes
but what changes do i make??
Edited to add the text from the answer made by the person who created the question:
i was writing to c:\programfiles\abess\ and the installer runs successfully the installed program does not run ,i am using windows 7 home and using administrator account
Is it trying to write any files to C:\ on a Windows 7 (or possibly Vista) machine? If so, by default you won't have write permissions there (assuming the C: is the system drive). Make sure that your app writes any files to subdirectories of C:\, like C:\Temp\ or similar.
I'm fairly certain that if it works on D: but not on C: it won't be a problem with the registry.
i was writing to c:\programfiles\abess\
and the installer runs successfully the installed program does not run ,i am using windows 7 home and using administrator account
after installing if the program is run as "run as administrator" it runs successfully
i am making the installer i can't be sure if on the other end user installs on c:\programfiles\ and gets frustrated when program does not run
We have a program that the installer checks for the existence of a config file, and if it exists, it doesn't copy that file over (it assumes the user has modified their config file and wants to keep those modifications). Unfortunately, this is a pre-Vista application and it keeps the config file in Program Files. The problem is, if you manually wipe out the directory when it re-installs certain API still thinks that there is a directory there. VB6, for example, and its browse for file dialog sees the folder, however explorer, cmd shell, etc cannot see folder. Writing over the file still leaves the old file there (to some API's, but not to explorer) which cannot be removed except form within the Browse for File dialog.
What is going on with these Phantom folders, and how do we delete the file so that all API's see the same thing? Maybe it has something to do with TxF, or the indexer for search, but both the installer we use (InnoSetup) and parts of the application (the parts written in VB6) are seeing the old version of the file, and everything else sees the current version.
As Oskar Duveborn said, it's very likely that what you're seeing is Vista's virtualization behaviour.
When a machine has User Account Control (UAC) enabled, standard users and non-elevated programs aren't allowed to write to the Programs folder. Windows instead silently redirects files to the appropriate subfolder of %AppData%\Local\VirtualStore (for example, C:\Users\MyUser\AppData\Local\VirtualStore).
If you browse the real folder in Explorer, you'll see the 'Compatibility Files' toolbar button, which you can use to browse the virtual store instead.
Note that this is only compatibility behaviour from Windows - your program should write to its own subfolder of %AppData%.
For more information, see this TechNet Magazine article.
Dunno if I'm on the right track, but doesn't Vista virtualize %programfiles% for applications that tries to write to it or otherwise are flagged as "not going about this the right way"? (and hence moves it somewhere into the user part of the filesystem instead, without telling the legacy app about it - making it kinda transparent)..?
Virtual Store Redirected files are stored somewhere in %appdata% - you can also find out the location by checking the "Compability Files" option in Explorer when at the aliased location. You need to stop writing to %programfiles% to get rid of this behaviour as far as I know.
Do you mean the AppData folder (C:\Documents and Settings\UserName\AppData)? I'm not on my vista machine, but I think that's the path, and afaik it's not wiped after an uninstall.
The TechNet link by Ant above (accepted answer) is no longer valid. The new link is:
http://support.microsoft.com/kb/927387 - Common file and registry virtualization issues in Windows Vista
This is a strange one to me. Let me list the setup:
Application with a manifest (ie: wont get pushed to virtual store)
UAC is turned on (can't write to other program files directories, or other areas, and uac prompt appears)
Can write to "c:\program files\%app_name%\%directory%\" both from within my application (not run as admin) as well as a non admin command prompt
Can not write to "c:\program files\%app_name%\%directory%\%subdirectory%\".
Any ideas? Are there hidden permissions or registry settings somewhere? Could it be that this directory was created when UAC was off, so now its fair game? Could it be that this directory was created in a time of XP, and its fair game?
It makes sense to me why i can't write to the other program files directories and the subdirectory. However I have no idea why i am actually allowed to write to the %directory%?
Side note: If I move the %directory% to another area (appdata), I still can not write to the subdirectory (confused).
Let me know any ideas you may have or anything I can check.
Thanks
EDIT: Arr, sorry, I skimmed your post a little too fast, looks like this is a non-issue!
Have you looked where the written files are actually going?
Vista has a feature where files written into Program Files folders by applications get redirected to a local per user store. This store is located at %userprofile%\AppData\Local\VirtualStore
This is to allow legacy applications which wrote per user settings to Program Files to still operate correctly, also allowing multiple users to use the program without conflict.
There's a button in explorer called 'Compatibility Files' which will take you to this user store.. perhaps your writes are ending up there?
I'm not sure why you cant write to the subdirectory though. Security permissions?