Jan Dubois
Thu, 06 Nov 2008 16:45:16 -0800
File Commander should have an "asInvoker" manifest. That way it manipulates the normal filesystem. You can still run it elevated by starting it from an elevated cmd.exe session, or invoking it with "Run As" from the context menu, or even have a separate shortcut with the "RunAs" setting set to Administrator.
You should be able to add the manifest yourself using a tool like mt.exe from
the Windows SDK, or reshacker if you don't have the
SDK installed. This way you don't have to wait for Brian to make another
release.
One thing I would like to see would be different color sets that FC would
automatically choose based on whether it is running as
admin or not (checking the actual process token to see if the process is
elevated and not relying on whether the user is a member of
the Administrators group).
You can kind of do this yourself too by having FC installed twice, configured
with different color schemes, and then make
corresponding shortcut icons that run one with normal privs and one as admin.
The main annoyance is that changes to directory
shortcuts are not automatically propagated to both instances. On the other
hand having separate command histories for normal and
elevated instances is actually an advantage. Personally I like using a red
background for shell windows that are running with admin
privs to make it real obvious that I should be more careful about things. J
Cheers,
-Jan
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Dr. Georg
Czedik-Eysenberg
Sent: Thursday, November 06, 2008 3:43 PM
To: File Commander mailing list
Subject: Re: [FC] Strange behaviour in Vista
Dear Jan,
many thanks for the perfect explanation of this tricky Vista function.
The question is now:
Should a tool like File Commander better have a manifest (with "run as
invoker") to ensure,
that we get informed when we try to modify a file without permission,
i.e. it sees and modifies files like the other (modern) programs do?
Or is it better, that it has no manifest and therefore sees and modifies files
like legacy programs do?
Or is there some third possibilty (like being able to switch between these two
modes)
or being warned, when VirtualStore is used ... ?
Kind regards, Georg
On Thu, 06 Nov 2008, Dr. Georg Czedik-Eysenberg wrote:
I found a very strange behaviour in Vista:
File Commander (started normally, not in admin mode) allows me to copy
files into "C:\Program Files" and also to create directories there,
but both are only seen then by File Commander, not by any other software
(like "cmd" or Windows Explorer).
Similar when I edit the contents of files there (using File Commander's
internal editor).
Can anybody else reproduce this effect?
You are encountering the "VirtualStore" feature of Vista: When running an
executable, it will check if the resources contain a manifest that tells
the loader the required privilege level (run as invoker, run as administrator).
When the manifest specifies "run as administrator" then you'll get a UAC
prompt to request permission to run with admin privs and after that you are
free to write to "C:\Program Files".
When the manifest specifies "run as invoker" then you will run without admin
privs, and the program gets a permission error when it tries to open a file
for writing in the "C:\Program Files" area.
When you don't have a manifest though Vista assumes you must be some kind
of legacy program that doesn't know about the stricter permission enforcement
of Vista. Instead of generating the permission error Vista will create
a shadow tree in your user directory, normally
C:\Users\USERNAME\AppData\Local\VirtualStore\Program Files
When you open a file for writing in the C:\Program Files tree it will first
be copied to this VirtualStore and then opened there. You are free to modify
any files in C:\Program Files this way, but you won't actually update the
real (protected) files.
Similarly when you read a file from "C:\Program Files" and don't have a manifest
then Vista will first try to open a file in the VirtualStore and only if it
doesn't exist open the real file (in read-only mode). This way the caching
happens lazily only for files that actually get opened for update.
Things are even more convoluted when you are running 32-bit applications on
64-bit Vista (in addition to the VirtualStore there is also file-system and
registry redirection for specific trees).
Only slightly related is one other feature: If your program looks like it
might be an installer, then Vista will assume that you want to "run as
administrator" even when you don't have a manifest. The heuristics for
"looks like an installer" are not fully documented, but include having any
of the substrings "setup", "install", "patch" or "update" in the filename.
So if you ever wonder why you cannot run patch.exe normally from a
cmd.exe prompt, that's why. There is a policy for these heuristics that
you can disable in the policy editor. It is enabled by default for
machines that have not been added to a domain (I guess with the assumption
that users in a domain are normally not supposed to install software
themselves).
It is all a very clever way to provide backwards compatibility while still
improving security. It is a nightmare though to figure out what is really
happening on your machine.
Cheers,
-Jan
PS: There is more stuff, like the automatic application of compatibility "shims"
to applications to work around known compatibility problems, but this post
probably already contains much more than you wanted to know about Vista.
_______________________________________________
Fc mailing list
Fc@silk.apana.org.au
http://silk.apana.org.au/mailman/listinfo/fc
Bug Tracker: http://bugs.silk.apana.org.au/
_______________________________________________ Fc mailing list Fc@silk.apana.org.au http://silk.apana.org.au/mailman/listinfo/fc Bug Tracker: http://bugs.silk.apana.org.au/