Need permission to delete file when logged in as sysadmin?

This is a strange one. While logged into the administrator account, I
moved a 700MB avi file from a folder in C: to one in D:. I'm quite sure
I right clicked and picked "Move" rather than "Copy" when I did this.

Afterward, though, I saw that Vista had copied, rather than moved: the
file was now in both places. No problem, I thought, only mildly annoyed.
I'll just click the copy on the C: drive, hit Delete, and ...

"You need permission to perform this action."

What the ****?

I'm logged in as administrator. I should be able to delete any damned
file I please.

It's not that the file's in use, either. For one thing, it isn't in use.
For another, that's not the message I get. In fact, I get the
"permission" message as soon as I hit Delete, without an "Are you sure
you want to move this file to the Recycle Bin?" first. The "in use"
message comes up AFTER the confirmation prompt -- usually, several
SECONDS after, with the machine spinning for a while first trying to
delete the file. This "permission" message pops up instantly.

The weirdest thing is that it has a "Try Again" button, which obviously
doesn't work (if you don't have write access to a file right now, you
generally never will, and it's especially unlikely that you'll suddenly
have it just a few seconds from now, or that you'll leave a dialog box
like that up for minutes, hours, days, or more, locking you out of one
of your Explorer windows until you dismiss it).

Next time I reboot I'll try it again; that seems to be the method of
second resort for fixing most buggy Windows behaviors (with simply
trying again right away a couple of times being the first resort).

Note to Microsoft: having files sometimes not writeable by root may
*seem* like a great way to make the OS more idiot proof, but

a) you underestimate the capabilities of idiots;
b) there's no logical reason to ever apply such a thing to anything but
key system files and registry keys; and
c) the PROPER way to do this is to make the default user account have
most, but not all of the privileges of a true root account, and have
one of those as well which DOES allow deleting any file whatsoever
(preferably including if it's "in use"). The special protected files
can be made non-writable by the almost-root account. Directories like
Program Files and Windows, and key parts of the registry, can also
be made unwritable or even unreadable by non-root accounts.
Alternatively, to avoid confusing users who want a KISS box, instead
of separate accounts with separate logins, have the administrator
account have a normal mode and a power mode, basically as above.
Normal mode still allows the user to install and do most stuff; power
mode lets them directly monkey with any file or registry key. Power
mode has to be enabled in control panel "System" and then there's a
tray icon you can reveal and then use to put the system in power
mode. Power mode can also disable UAC and a bunch of other stuff that
tends to annoy users that know what they are doing and that are doing
power mode things. (UAC can be made even less annoying by adding
1) a flag that can be set on programs that says "this is an
installer" and
2) a feature whereby if a program with this flag set is fiddling with
the system, the UAC prompt you get allows you to check "trust this
installer and don't prompt me further about its activites this
time"; if checked and the UAC request granted, until the installer
exits it will not produce any more UAC prompts via its actions,
which will be auto-allowed. This will stop the current irritation
with starting an installer, answering about ten UAC prompts in a
row, then some progress bar starts crawling slowly, you leave when
it has reached 2% after ten minutes to take the dog for a walk,
and when you get back half an hour later rather than being at 8%
it's only at 3% and another UAC prompt has been waiting for 25
minutes for your attention. Rather than nursemaid it all night you
disable UAC before going to bed.
Oh, and trusting an installer should be transitive to any child
processes it launches to do parts of the installation, like an
unzipper that extracts a bunch of DLLs directly into
Windows\System.

Note #2 to Microsoft: if rebooting frequently to recover from problems
is going to be as necessary for the next 20 years as it has been for the
last 20, please streamline the motherfucking process! That means adding
an API to Windows 8 via which applications save session state (what's
open, what windows are where and how big, etc.), and making everything
(not just Explorer) save that stuff. Autosave that stuff every few
minutes, so it survives things like power failures as well as planned
reboots. And last but CERTAINLY not least, bootup needs to be faster.
Two orders of magnitude faster at least. Caching aspects of the
post-boot state, such as relocatable core images of data structures such
as loaded fonts and the most usual drivers and that, might help. In
fact, why not just have any reboot after a system modification (updates,
etc.) save a hibernation file as soon as the system's up and running,
without actually hibernating the machine and not in the usual location,
and a normal reboot actually boot from this file as if de-hibernating.
The boot menu can provide an option to do a slower reboot, in case this
gets corrupted somehow, and a failed startup will cause an automatic
slow reboot by default. Session state restoration occurs after either
kind of reboot, but if IT gets corrupt, there can also be a "clean, slow
reboot" option on said boot menu, and automatic resorting to that if a
fast reboot and then a slow, session-preserving reboot both fail. If the
automatic clean, slow reboot also fails, for that matter, have it do a
clean, slow reboot in Safe Mode as the fourth try, and give up and whine
to the user at a timerless boot menu only if that also fails. If it gets
all the way to Safe Mode and then works, a popup can suggest that the
user roll back one System Restore point.

It would then be nice if a fast reboot is possible after most installs
(preferably, all installs of non-kernel-mode stuff). This SHOULD be
possible: the usual reason such things want reboots is to register
updated DLLs that were in use or some such thing. That really only
requires applications exit and restart, so why even do a full reboot?
Just close all applications as if preparatory to a shutdown, then
register the DLLs, then (without actually rebooting the OS) act as if it
just rebooted, reopening them and using the new API to tell them to
restore session state. This should be faster than even a fast reboot. If
something goes wrong (say, a DLL registration fails), fall back on a
real reboot.

 

http://ccollomb.free.fr/unlocker/
Download Unlocker 1.8.9

MD5: a9609c0a8d15bac20bd46d6500679f9a / SHA1:
17a789708147a14df46b4be052e8e8632992552a