So here's the lowdown, I've disabled UAC due to plain annoyance and lack of any real protection (it only stops automated tools not people) I am an administrator (admin account is still disabled but as only user I'm part of the admin group) I've taken ownership multiple times of my entire drive (this takes forever on 300k+ files), this deals with the ownership problem for about 5 minutes before it start complaining again. The worst part is when I go to install an application and I go immediately into the installed folder and attempt to modify/delete/overwrite files. The files are marked as such; users group has everything but write, trusted installer only has list, and creator owner/admin both have nothing. This obviously poses a problem, and I get a permission denied error. I then go try and take permission and get denied (seriously? i'm the admin user) and eventually after using a take ownership script I found am able to take permission on the folder. I can then go and try to delete the file, It starts saying that the file can't be found, It is clearly still there, even after multiple refreshes to the folder. So I noticed that msiexec is still running after every installation, for some reason refuses to quit. I've since disabled the service to keep it from running before installing a program. even if it insists on doing so during. Once I quit I can wait around 5 minutes and all of a sudden my commands will all go through. The ownership will pass, the file will disappear and it will all act as normal. I've also found that ending explorer and restarting it can speed up this 5 minute process. But seriously it should not take 10 minutes to delete one file that I've just put there. I'll say that I've experienced this problem on multiple versions of Win7 and on both architectures. Had similar problems with Vista back in the day but they were all correctable with the take ownership command. I've searched forums for months every time this problem comes up and all I get are people saying that UAC protects us (I can protect myself thanks, I'm fairly competent and already have multiple certifications) and disabling it is a bad idea, No real fix. Today I just got fed up with having to do this every hour and decided to start my own thread, hopefully this one will stay on topic, Mods if you can help prevent thread hijacking that would be awesome. As much as I really don't wanna go this direction I'm seriously considering switching to Debian to avoid this. I wouldn't have this problem in wine. What's going on and what can be done to correct this.

As you've already compromised the security of Windows 7 you may as well activate the Administrator account and use it. This should accomplish what you want. I don't recommend it but it will do what you want. Sorry for this lecture about security but many people will read this as it's in a public forum and I want them to understand why the security that you don't like exists. XP is not and cannot be made secure. Vista and now Windows 7 were programmed with security in mind. They are much like other operating systems that are claimed to be more secure than XP. Most modern operating systems are setup to run as a standard user with no write access to system files. Even XP and older versions of Windows based on NT are setup this way. The problem with these older versions of Windows was that everyone logged on as an administrator user negating this security. It is equivilent to logging on as root or superuser in other operating systems. Users of those OS's would laugh at you for doing this. For whatever reason users of Windows expect this and it became the norm. Because of it malware flourished and the Internet became a very dangerous place for Windows users. Microsoft knew Windows users (and more important software developrs) would not change their habits and thus UAC and other measures were born. Please do not change the default security settings. There is nothing that can't be done in Windows 7 that you could do in XP. You just have to learn new ways to do it. Some of these new ways may be inconvenient or take longer. Inconvenience is always associated with higher security. That's a fact of life that applies to more things than just computers. As with other things in life we have to learn to accept some inconvenience if we want better security. If everyone using Windows 7 changed their security as Paintball9029 has done malware will continue to flourish and probably get worse. At this point malware has become too lucrative for it to go away but why lower the bar for the malware developers by going back to XP like security? Kerry Brown MS-MVP - Windows Desktop Experience

I don't think you get what I'm saying. I am NOT trying to access files that should ever be locked. The file's I'm changing are not in the windows directory, they are in program files in the third-party program installation folders. I'm not only being blocked from creating them I'm also being blocked from deleting them. I am very aware of what security does and does not prevent. This is not one of them. I am fully confident this is a bug rather than a security feature. Protecting the windows directory from write access is security, requiring user input through a physical input device is security, stopping a user (regardless of the permissions they have) from deleting a file they have just created is not security. As I mentioned above this problem most commonly occurs directly after installing a program, and at that time the executable msiexec.exe remains running. This file should be quitting with the installation but it is not. As long as this is running I can't change anything. Its only after ending the task and waiting a few minutes that I get permissions back. Even the administrator account would not be able to make changes in this situation. Under permissions every group is lacking in write permissions and strangely enough only the users group (not even the owner or administrator) has the ability to read.

Folders where you install programs that all users can use are protected in a secure OS. For example in Linux /bin and /usr/bin are protected. You need root access to modify or delete files there. Windows Vista, Windows 7, and even XP protect the Program Files folder from standard users altering or deleting files. The only reason you could seemingly do this easily in XP is because you were logged on as an administrator. See my first post for why logging on as an administrator in Vista and Windows 7 works differently from XP. Not protecting the Program Files folder would allow malware or even just a poorly programmed application to cause havoc with the system. If a file is open it cannot be deleted no matter where it is or what permissions you have. This is normal. The installer normally stays open for a while even after it appears the install is finished. It may be cleaning up files and doing other background tasks that don't affect the use of the newly installed program. This is in the interest of usability. It would be very unusual that someone would want to delete a file from a newly installed program folder immediately after the install. That's clearly an edge case that you will have to live with. I don't think that would ever be changed as far more people would complain about long installs than needing the ability to delete files immediately after the install. Kerry Brown MS-MVP - Windows Desktop Experience

You're mistaken, if the program using the file were the cause it would result in a file in use error, not a permission denied. Remember what I said about every user lacking permission, even administrator's and owners. I've also seen this Windows Installer service stay active for days. This has gone to the point that I actually look for it every once in a while just to close it down should it be altering permissions on my other files. Even completely disabling the service has no effect on it. As well there is no possible way for that program to decide to 'use' every file in a recently installed folder at the same time. At most you should see 1 file being used. I havn't tried this yet, but I will. I believe that if I installed to a separate drive or user folder somewhere it would still lock the files. IMO No program, Microsoft security or not should be able to lock out the owner/top administrator, yet somehow it manages to. The thing with security is that there always has to be someone higher than it to impose the restriction. If it really is what you say (background tasks/clean-up) then there should be a registry entry to disabling that. Like a disable caching function. The only reason I really need access to 'critical system files' through a truly root account is that windows lacks proper elevation. UAC does nothing more than restrict low end users from performing standard functions. I need a true sudo-like function and that doesn't really exist on windows OS.

This is clearly a windows/windows installer bug. When are we gonna get a patch for this?

The worst part is when I go to install an application and I go immediately into the installed folder and attempt to modify/delete/overwrite files. The files are marked as such; users group has everything but write, trusted installer only has list, and creator owner/admin both have nothing. It would appear your attemts to circumvent the built in protections which you are blindly disabliling have altered your permissions. I would ditch that permission script mentioned (or update it if you wrote it) and start attempting to work with the systems built in to control such access. Not having the local administrators group with full access to any 'Program Files' or 'Program Files (x86)' subfolders is not normal and indicates that your installation has been changed (likely by your actions).

That's the problem though. Without 'circumventing' I can't do anything. Those systems built in to control are even worse. My main concern is that the security system has been built in the wrong direction for windows vista and seven. When you work with permissions there is always someone at the top of the list who can do everything. However here it seems to have been done in the wrong order. The admins (which by definition should be the highest on the security chain) are second, and the top (msiexec.exe from what I can see) is malfunctioning and forgetting to give permissions to those lower down the list. As soon as you rely on a script/program to keep the security in order you open it up to problems like this. There needs to be some way to return the top access to human control.

So I had a breakthrough on this issue today, hopefully either Microsoft developers or a user can learn from this. I installed a firewall recently (not the cause of this problem, so don't even ask). And I discovered I can use it to specifically block windows services. So that's exactly what I did. Msiexec.exe starts up randomly (when not installing programs), wrecks file permissions to the point of totally denying all access by even admin users, and just uses resources. Tried disabling it through services, somehow had a way to restart itself every once in a while. Anyways, comodo was successful in stopping it. See this screenshot. http://img835.imageshack.us/img835/741/msiexec.png The service is clearly disabled, yet it tries 8 TIMES to start. Comodo blocks it, I install a program (without problems, implying that windows installer service is NOT AT ALL required). Everything now seems to work properly, I havn't had a permissions problem since. AT Microsoft, FIX THIS ____. It's clearly not that hard. Or are you too busy refusing to fix widely known security vulnerabilities that you created.