A few months ago I changed the download settings on my computer (Windows 10) so that whenever I download a file from the web, it prompts me to choose where I want to save it (e.g. Downloads, My Documents, Desktop, etc). Before changing the settings my computer would automatically save most program files to the Program Files folder (naturally). But today I was trying to download the Anaconda/Python software, and I figured I should save it to the Program Files folder. However, when I choose this folder at the download prompt it says "You don't have permission to save in this location. Contact the administrator to obtain permission." But this is on my laptop, and I am the sole user. So how don't I have permission/how can I obtain permission?
Also, I've encountered this issue a number of times since changing the download settings and I've been saving program files to C:/Users/Leonidas instead...Could there be any bad consequences to saving it here instead of in Program Files?
Related
I have an executable file to install a software in Windows 7, which will unzip a number of folders inside it.
I tried with 1 computer and it worked. I tried with another computer and there left a number of folders that were not unzipped.
I assume this is some sort of Windows 7 security settings but I failed to google for a satisfactory solution.
Thanks.
I would need more specifics about the different machines you are using it.
If it is a security issue, you will be able to successfully run it as an administrator. Do this by right clicking on it and selecting Run as administrator.
If the user you are using is not the administrator you will be prompted for an account and password, otherwise you will see just an extend UAC warning message you can accept.
The nature of the .exe could determine why it might not successfully unpack as well as the location the files are going to when being unpacked.
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.
I have a Visual Basic 6.0 application that I want to install for All Users, for example, the setting are held in a single spot regardless who logs into the computer. I have the following code to locate the common location:
Const ssfCOMMONAPPDATA = &H23
Dim strAllUsersPath As String
strAllUsersPath = CreateObject("Shell.Application").NameSpace(ssfCOMMONAPPDATA).Self.Path
On Windows XP, this path points to C:\Documents and Settings\All Users\Application Data\ folder. The setup copies the settings file there and everything is great. The Visual Basic 6.0 app can change it at any time.
On Windows 7, this path points to c:\ProgramData folder. The setup, which requires administrator privileges, copies the file there. However, when my Visual Basic 6.0 application starts and accesses the file, Windows 7 copies the settings file to a C:\Users{USER LOGIN}\AppData\Local\VirtualStore\ and performs all the operations on it there. As a result, because for each user, Windows 7 copies the settings file to a separate user directory, the users end up having a different settings file.
Am I storing the file in the wrong location? Am I doing it in the incorrect manner?
This one has bitten me too. The ProgramData folder has shared Read Access, no shared write access. You can of course change the permission on the folder during install, but I think that goes contrary to how Microsoft meant it to be.
See this other question for some useful links
How Microsoft thinks it should be done.
I'm probably just being very thick here, but it's not clear to me where I'm supposed to install 'new' user-specific programs on Windows 7 (and presumably Vista too, though I've not specifically looked at that scenario yet).
Under Windows XP (rightly or wrongly) we always installed our programs into folders under 'Program Files' and accepted that they'd be kind-of available to everyone. From what I can gather under Windows 7 I'm supposed to install my software under the user's AppData folder (possibly AppData\Local\MyApp). That makes a degree of sense, but the fact that this folder is 'hidden' by default means that we're going to have 'fun' talking our users through support stuff.
I want to install our software so that it's user specific (the Users bit in Windows 7 makes perfect sense) but I do want the user to be able to access it if required. Our program also includes a 'data' subdirectory which it needs to write into while it's running (embedded database), but as the program is intended to be single-user/standalone, the data folder being inside a user-specific folder isn't going to be a problem.
My problem is just that whole 'hidden folder' aspect of AppData. As much as I've trawled the MSDN, I can't work out where else I'm supposed to install user-specific programs. Taken one way it would seem to be something like AppData\Local\MyApp, and another way it would seem to be just as valid under the user's My Documents\MyApp equivalent.
Has anyone got a clear guide for where all this stuff goes? I found the MSDN docs confusing. :-)
Not really.
The directory that serves as a common
repository for application-specific
data for the current roaming user.
AppData is, surprisingly, for application data, not for installation (Click Once/Silverlight applications aside). You can, and should still install into Program Files, just don't expect to write into that folder.
You can install software into AppData if you want it to follow a user about in an Active Directory environment, which happens if you put it in AppData\Roaming (the SpecialFolder.ApplicationData location).
You can also install into AppData if you want the software to be available to just the user that installs it. This can be useful if, for example, you have multiple users on the same machine, who all want to run different versions of the software in complete isolation.
If you want settings to only apply on the local machine then you use AppData\Local, which is SpecialFolders.LocalApplicationData - this will make AD administrators very happy as the roaming profile size won't suddenly jump up 50Mb or whatever the size of your software is.
If you wanted to create settings which apply to all users then you're looking at SpecialFolders.CommonApplicationData
You should remember never to rely on the actual name of the directory - localisation issues mean this can change and the location does change with OS versions two. You should be using the special folder enumeration in your software, or the equivalent in your installer.
Could you not install into Program Files, but use AppData as it's supposed to be used, and store your database in there?
Windows 7 added the FOLDERID_UserProgramFiles known folder and by default this maps to %LOCALAPPDATA%\Programs. This is used by MSI when ALLUSERS=2 & MSIINSTALLPERUSER=1.
On Vista and earlier there is no canonical per-user application folder but just using %LOCALAPPDATA% is pretty common. Sadly MSI will just use %ProgramFiles% on these systems.
It's 2019, and I just installed Visual Studio Code (a Microsoft product) in the default folder of
%userprofile%\AppData\Local\Programs\Microsoft VS Code
This is probably for getting around the requirement to have an administrator or UAC prompt authorise the installation
Windows 7 folder structure is deeply inspired on Unix structure:
/usr/ -> C:\Program Files\ -> binaries: executables and dynamically linked
/etc/ -> C:\ProgramData\ -> global settings
/home/ -> C:\Users\ -> a folder for each user
~/.* -> C:\Users\Hikari\AppData\Roaming\ -> settings for each user
Windows has more folder, like My Documents for files with content produced by user, AppData Local and Roaming (which Unix usually handles with NFS).
It's about time for us developers to start using these structures. We must separate at least binary files that don't need to be replicated, global and user settings.
When a setup is installing an app, this setup should expect to have permission to write on Program Files. Once the setup is finished, Program Files should be writable only for other setups aiming to update binaries to other versions.
Please install executable files to the %programfiles% folder in Windows - a simple MSI based install package can perform an active setup for any new user who logs onto the machine to create the user specific files and folders in their profiles %appdata% folder. You see this behaviour for Internet Explorer, Adobe reader, etc. - It's the little MSI installer window that pops up the first time you log onto a machine which has those applications installed. - Thanks - a system admin :)
My opinion, for what it's worth, is that user-specific program files is just asking for trouble and is a damn stupid thing to do.
A much more sensible approach is to install different versions of your program to:
\Program Files\Your Program\Program_v0.1\Program.exe
\Program Files\Your Program\Program_v0.2\Program.exe
\Program Files\Your Program\Program_v0.3\Program.exe
\Program Files\Your Program\Program_v0.4\Program.exe
I would then place a bootstrapping launcher at:
\Program Files\Your Program\ProgramLauncher.exe
Then, the user application data folder will only contain data, including an INI/XML/Settings file that indicates the version of the program that this user is working with.
Such an approach satisfies the core tenant of keeping data and executing code separate, allows every user to run a specific version of the code, and offers a small amount of de-duplication by ensuring the same executable code is not copied multiple times across user folders.
Otherwise, go right ahead with installing programs to AppData and undoing the years it has taken us to achieve clean separation of code and data. I found this thread because I noticed that Chromium and DropBox are installing code to AppData. I'm going to uninstall those program, and change the permissions on my AppData folder to exclude execution to ensure I can easily spot other programs attempting the same BS.
I wonder about this because we are developing an application, after installation some files were copied to program files and some to user profile directory. But, we found some issues w.r.t program files. Now all files are installed in the current user's directory. Even Google Chrome, does so. What do you think?
If you install a given application on 10 different accounts, do you really want the application to exist 10 times on disk?
The program files directory is for just that, the executable files, dlls, assemblies and other executable code and non editable configuration data associated with a program. The user profile directory is for data and code associated with the individual user.
The program files directory in Windows is a place where all the installed files go.
But there are some customizations needed depending on users. Those go into user's directory.
Like Downloads folder, customization of Mozilla firefox, Winamp, etc.
There has to be different profiles for each user to customize the applications.
But the commonly needed files of a software need not be installed in each user account; hence they are installed in Program Files
Since Vista the Program Files directory has been marked as off limits so applications can't write to it by default unless given admin privileges.
This is for better security to stop other applications manipulating existing installed applications.
There is a good write up of this here on how to work with UAC but also learning to write more secure applications.
http://msdn.microsoft.com/en-au/magazine/cc163486.aspx