I created customized brush using gimp.While I tried to save it in gimp directory, following error is obtained."'C:\Program Files\GIMP 2\share\gimp\2.0\brushes\mybrush.gbr' for writing: Permission denied". Please help me how can I get access permissions.
I assume you're on Windows 7. Whenever you got errors that you do not have the correct rights while saving items/files you need to get administrator/root access on GIMP.
In windows you can do this by rightclicking the .exe/icon and look for the option "Open/Run with Administrative rights".
Not sure how one would do it in Linux but I assume you'll have to run your program with sudo and/or root access by -su.
When you have administrative rights you should be fine saving everything on the desired location
By default, in Operating Systems where normal users can't create files anywhere on the disk (like any age Linux, or Windows 7), GIMP's default resource folders are installed with the program, and are system wide. These folders are not writable by users without administrative rights.
Running GIMP with administrative rights could, of course, override this problem, but this is not "the right thing to do". What you have to do is go to edit->preferences and on the appropriate Folder resource, create a new folder, this time as a normal user, where those resources will be kept.
From them on, write operations will happen on the newly created folder.
Right-click on .exe (.exe-icon) ---> Properties ---> Compatibility ---> Input Setting = Uncheck "Turn off advanced text services for this program"
- Hope that Help !
Related
I need the following information
How to get "C:\Document and settings\Network service" folder of XP OS
programmatically from Delphi2010?
What is the equivalent of above folder in Vista and Win7 OS ?
I need to set the Network Service"
account full rights for the above folder thru Delphi 2010
Any help on the above is highly appreciated!!
Thanks in adv
Ven
Here you go:
1) For WinXP: Use SHGetFolderPath API with CSIDL CSIDL_PROFILE to get the folder of your own profile (e.g. "C:\Documents and Settings\Steve"), remove your own name (the Steve part) and add NetworkService (giving you "C:\Documents and Settings\NetworkService"). There seems to be no direct way to get the Documents and Settings folder.
(Example for SHGetFolderPath usage: http://delphi.about.com/od/kbwinshell/a/SHGetFolderPath.htm)
2) For Win7 the location changed to "%windir%\ServiceProfiles\NetworkService", this is commonly "C:\Windows\ServiceProfiles\NetworkService". Don't know for Vista, might be the same.
3) The easiest way seems to be the approach described here: Create folder/file and set permissions
You can start the CACLS programm via ShellExecute API. See example of usage here: http://delphi.about.com/od/windowsshellapi/a/executeprogram.htm
i can use the copyfile(); function to copy a file to c:/windows/system32 on windows xp but then i use the function on windows 7 i cant copy it:o the file wont come there....
i had the same problem with writing and reading registery but fixed it by declaring a WOW key $0100 ...
i think the problem is uac but not sure.. could somebody explain me that:D?
That is indeed because of UAC. It is called File/Folder or Registry Virtualization. It is done for legacy applications who don't yet respect the new UAC rules (e.g. not writing in system folders unless you are an administrator).
By creating a manifest file you switch off this virtualization. See here. This can be a seperate file or be embedded into the exe. Newer Delphi versions already generate executables containing such a manifest and have requestedExecutionLevel set to asInvoker. This normally does not allow writing in those locations, unless users specifically run your program as an administrator. Setting it to requireAdministrator does allow writing in those locations, but also means users have to confirm they want to run your program as an administrator.
It's indeed UAC that's preventing you from copying files to the system32 folder. You have to ask yourself why you want to copy files there. A normal application should never copy files to the system32 folder.
Sometimes during install you might want to copy dll's there, but even that is legacy behaviour. Should you really want to copy files there, you should request Elevation at the start of the application.
Why are you copying files there? It should be treatead as the OS private directory. Unless you're installing a driver or the like, you should never write there. In XP you can only because you're running with Administrator privileges, try to use a plain user and you can't as well (since at least 2000, if not in NT already), but it will give you an error because it won't redirect the write. Unless you have a truly good reason to write there, I'd suggest to redesign your application to write in the proper place, instead of trying to find a way to write there. Anyway, it will fail anytime the user don't have the privileges and can't perform an elevation.
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.
After many months of postponing it, this week, I finally started using a new Windows 7 Professional PC for actual development (which is 90% still done in Delphi 7 with some of these programs still using the Borland IDAPI to access Paradox files). The previous development pc was still an XP-one.
Every thing works except for one thing: somehow the settings of the IDAPI and BdeAdmin configuration files are messed up or they are read/written in different locations. To be more precise, it looks like two configuration files are active.
It must have something to do with rights or settings being read/written in the wrong folder or registry setting, but after searching for it for a couple of hours, I give up.
Anyone had any problems with this, before ? And if so, hopefully, has any one solved this problem ?
Thx for any thoughts/solutions ...
My guess is it has something to do with the fact that Vista and Windows 7 don't allow programs to change files under the C:\Program Files folder. They create a copy of those changed files in a virtual store, the process is known as virtualization. The copies end up in the hidden appdata folder of the user account and can be found in the Local\VirtualStore\Program Files folder. The structure in that folder reflects the one in the actual Program Files folder.
Programs that access their files in the Program Files folder using a "hardcoded" path, will always get the original - unchanged - file contents.
Solution: running the apps in a virtual XP system or upgrading the apps is probably your best bet.
You could try to run the apps elevated. That is: right click them and choose Run as Administrator. Please note that it isn't enough to be logged in as an administrator. Even administrators run all processes unelevated by default. Instead of right-clicking, you can also create a shortcut and set the Run as administrator for the shortcut - the checkbox for this is on the compatibility tab of the properties dialog. No guarantees though that this will alleviate the problem.
Since IIRC D7 setup allows you to configure paths in multiple ways, maybe simply do a reinstall outside "program files"?
Afaik this solves several vista/w7 problems.
We have a suite of programs that check for new versions at startup, and then download new versions to run if required. This is obviously a problem in Windows 7, when it is locked down as a 'standard user', as they can't write to the c:\program files directory and below. Anyone seen a example of an application that gets around with issue ?
Our applications are written in Delphi, but an example in any language would be useful.
Thanks in advance
Update:
We already have a system for determing whether a new version exists, the only problem is the download and install (if required), as this requires elevation. I can't think of a way that doesn't require an elevation prompt, or our users to reduce their security settings.
Update 2 :
I've asked a subsequent question, rather than adding a new one here
There are two options for application installation:
Application is available for all users: installation or update requires elevation for Windows Vista and up
The application is available for one user: install or update the application in the user profile in %LOCALAPPDATA%, no elevation is required
Ad 2: Google Chrome does this. It installs the .exe here:
%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe
--jeroen
Typically what you will see an application do if it needs to escalate permissions is something like this.
Application determines if upgrade is needed
Application launches an "updater" service that requires "Administrator" permissions
Application updates itself with this updated
Application re-starts
This is a pretty common scenario, especially since to update your own DLL you need to go to a secondary process anyway.
Here are some tips for you to get around updating challenges:
If your file is names 'update.exe' or 'install.exe' then it will automatically force a UAC elevation prompt. This is an easy way to make existing software bypass Windows Vista/7 permissions.
It is not a good idea to have the update checking and update process managed from within your application. The problem is that your app is likely to lock files and need updating itself. An external app should manage your updates.
The simplest update solution is to make an HTTP call that checks for the current product version number, and then download the installer binary if necessary. This won't give you any flexibility in updates, but it is a quick and easy solution.
Our company sells software that specifically helps with automatic updates on Windows 7 UAC (you can visit AutoUpdate+ by clicking here: link text). The best reasons for using a third party solution - any solution - are that you will have more flexibility with your updates and also avoid the finicky challenges of supporting different Windows releases.
Or you can have it so that the user runs a launcher app.
The application uses the LOCALAPPPATH\ folder to store a cache of the main application.
Launcher checks to see if the internet has newer version of file(s) than the cached file.
Launcher launches the cached application in LOCALAPPPATH
Your app can check if a new version is available on the remote server. If it does, then it can download update files in one of user-specific folders, like user's temp folder. You can get address of such special folders using SHGetSpecialFolder API function.
Once the download is done, you can pop up a dialog box telling user that you are ready for update. If user agrees with update, then you can run the updater process with elevated privileges (as administrator), and updater process can replace existing files in your installation path with the ones already downloaded in user Temp folder. To run your updater as administrator, you can use ShellExecute:
ShellExecute(0,'runas','notepad.exe',nil,nil,SW_SHOWNORMAL);
When updating is done, your updater process can restart your app.
You need to have a separate executable to the updating work. The updater needs to have a manifest that marks it as requiring elevation.
See: http://msdn.microsoft.com/en-us/library/bb756929.aspx
If your application uses MSI (Windows Installer) for its installer, then User Account Control Patching, if properly configured, can let you install updates without elevation.
If your installer wasn't run under admin - you don't need any additional rights to install update.
If your installer was run under admin - then it can create a task in Task Sheduler. Say, run this task once a week, under this account (admin) and with highest privs. Task will be your updater. Simple.