Alan,

This is more "gut feel" comments on your uncertainty about the
virtualization of data intended for all user access.
I believe this is outside of the scope of  / intent of this virtualization,
which is to my awareness always writing the virtualized values on
a per account basis.  If an account is supposed to be able to
write data for all users the system will reflect that and virtualization
will not come into play.  If it does not then the persistance should
be for only that account, since the system says impact on all accounts
should not be allowed.
Again, this is a gut feel response, but it is based on a few talks
over the past year and a half with some of the folks that came up
with virtualization.

Roger

I have mixed feelings about this file/registry virtualization.  Actually I
think this is INSANE!.  UAP is aimed at making administrative accounts into
limited user accounts to prevent unknowingly granting a process
administrative rights where virtualization appears to grant every process a
"virtual administrative privilege" within the context of the user account
only, in effect all the ACLs are [virtually] disabled allowing application to
replace system registry settings and program files that would ordinarily
result in an access denied error.  Does the left hand know what the right is
doing?  I don't get it.  Personally I don't care if the application enables
outlook scripts and macros only for my user account or replaces internet
explorer with a look-alike that records usernames and passwords for my user
account only.  IMHO this is a big mistake and effectively grants the user all
the necessary permissions to completely trash his [virtual] environment
leading to a new class of malware eventually forcing the administrator to
delete his user profile and recreate it from scratch and with more and more
applications installed in this virtual environment it might become almost as
much work to reinstall your applications and reconfigure your preferences as
it is today after a fresh install of windows XP.  I don't think
virtualization does anything to protect the user rather the only thing that's
being protected here is the system which is overshadowed and hidden by the
user's virtual environment where every process [virtually]  has
administrative permissions, so what exactly have we gained by this?

Perhaps I'm missing something here, and hopefully its not as bad as I think
it is, but IMHO virtualization should be considered nearly equivalent to
granting administrative privileges and thus only be granted with explicit
user permission much like UAP.  Additionally I think each virtualized
application needs to be isolated, perhpas some sort of "virtual process
domain" (something like IIS appdomains where multiple applications can share
an appdomain, such as the main applicaiton and a configuration tool, but are
otherwise isolated from other appdomains) and going further the virtual
process domain should have a associated virtual user account (ie file and
registry virtualization right in local security policy or something like
that) which is used when the user runs an application in that process domain
(somewhat like administrator having a split token) thus allowing ACL
permissions to be refined as necessary for that virtual process domain, such
as virtual user and own new program files folders but not modify existing
ones not created by that virtual user thus minimizing the risk that the
application might attempt to replace and launch a fake internet explore when
user clicks on a link on an application within that process domain for
example.

So, any application, irrespective of when it was created, will see its
writes succeed, when it tries to write inside "Program Files" or "Windows"
directories ?  Is there a way to turn off this behavior (only for this app)
so that it fails instead of succeeding ?

If not that, is there a way to check if a write operation was successful due
to virtualization kicking in lieu of having sufficient privileges ?

Thanks,
Saurav.