Need permission to delete file when logged in as sysadmin?

Discussion in 'Windows Vista Talk' started by Speed Dial, Mar 20, 2010.

  1. Speed Dial

    Speed Dial Guest

    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.
     
    Speed Dial, Mar 20, 2010
    #1
    1. Advertisements

  2. Speed Dial

    bugs Guest

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

    MD5: a9609c0a8d15bac20bd46d6500679f9a / SHA1:
    17a789708147a14df46b4be052e8e8632992552a
     
    bugs, Apr 7, 2010
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.