Vista - File Locations to Avoid Virtualization

This has probably been asked before but I'm running out of time to get an
answer and my initial search turned up empty.

We have an application that runs as a stand alone application and also a
hosted "module" of 3rd party applications. We have found just recently that
one of our 3rd party host applications is certified on Vista and seeing our
Stand Alone application works on Vista (after getting past a couple of curly
issues; at least one MS bug in there) we want to also support our
application running as a module in the 3rd party app.

Problem that we are experiencing is that the 3rd party has done whatever
they need to do in terms of the manifest or what have you to indicate that
their application is Vista aware. This of course turns of file system
virtualization and we are running into a couple of issues when running under
that environment. The main issue is that I am finding our application cannot
access certain files that it should be able to access. We are basically
getting errors saying we cannot access the data in our company folder under
(C:\ProgramData\All Users\<Company Name>\<Application Name>\). But hold on I
thought, isn't this location the "correct" location for application data
that is shared between users? Then I thought that maybe our code is getting
to this location through virtualization and seeing it is turned off now we
hit the problem. So I tracked down the code and it seems we are doing the
right thing, or what I at least expected to be the right thing... we are
using....

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
Environment.GetFolderPath(Environment.SpecialFolder.Personal)

to build up all of our working directories.

So why is this giving us grief on Vista? Isn't this the recommended
practice? Seems like the first one on the list is giving us grief and I am
reading that this is supposed to be for roaming profiles. Maybe that is the
issue?

Please help, or let me know if any additional information is required....

Actually I have Vista open now and the location the starting files are
deployed to is:

C:\ProgramData\<Company Name>\<Application Name>\<SubFolder>\<SubFolder>\

not...

C:\ProgramData\All Users\<Company Name>\<Application Name>\

which I think is correct, and here is the exception...

System.UnauthorizedAccessException: Access to the path
'C:\ProgramData\<Company Name>\<Product Name>\8\Libraries\LiquidLibrary.xml'
is denied.

So the file is in the correct location (as far as I am aware) and we are
trying to access it at the correct location, yet we are denied? Why?


"Wayne Hartell" <w.hartell@ozemail.com.au> wrote in message
> This has probably been asked before but I'm running out of time to get an
> answer and my initial search turned up empty.
>
> We have an application that runs as a stand alone application and also a
> hosted "module" of 3rd party applications. We have found just recently
> that one of our 3rd party host applications is certified on Vista and
> seeing our Stand Alone application works on Vista (after getting past a
> couple of curly issues; at least one MS bug in there) we want to also
> support our application running as a module in the 3rd party app.
>
> Problem that we are experiencing is that the 3rd party has done whatever
> they need to do in terms of the manifest or what have you to indicate that
> their application is Vista aware. This of course turns of file system
> virtualization and we are running into a couple of issues when running
> under that environment. The main issue is that I am finding our
> application cannot access certain files that it should be able to access.
> We are basically getting errors saying we cannot access the data in our
> company folder under (C:\ProgramData\All Users\<Company Name>\<Application
> Name>\). But hold on I thought, isn't this location the "correct" location
> for application data that is shared between users? Then I thought that
> maybe our code is getting to this location through virtualization and
> seeing it is turned off now we hit the problem. So I tracked down the code
> and it seems we are doing the right thing, or what I at least expected to
> be the right thing... we are using....
>
> Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
> Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
> Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
> Environment.GetFolderPath(Environment.SpecialFolder.Personal)
>
> to build up all of our working directories.
>
> So why is this giving us grief on Vista? Isn't this the recommended
> practice? Seems like the first one on the list is giving us grief and I am
> reading that this is supposed to be for roaming profiles. Maybe that is
> the issue?
>
> Please help, or let me know if any additional information is required....
>

Yet more investigation and I am pretty sure that this folder is the
problem...

Environment.SpecialFolder.CommonApplicationData

Under XP this is:
C:\Documents and Settings\All Users\Application Data

Under Vista this is:
C:\ProgramData\

The problem is under Vista this folder is not writeable unless running as as
admin!!! What the? WHERE do we store application data that is shared between
users then????????????????? SpecialFolder.ApplicationData,
LocalApplicationData are both user specific!

I have to missing something right????


"Wayne Hartell" <w.hartell@ozemail.com.au> wrote in message
news:u8DZaxOQHHA.3960@TK2MSFTNGP05.phx.gbl...
> Actually I have Vista open now and the location the starting files are
> deployed to is:
>
> C:\ProgramData\<Company Name>\<Application Name>\<SubFolder>\<SubFolder>\
>
> not...
>
> C:\ProgramData\All Users\<Company Name>\<Application Name>\
>
> which I think is correct, and here is the exception...
>
> System.UnauthorizedAccessException: Access to the path
> 'C:\ProgramData\<Company Name>\<Product
> Name>\8\Libraries\LiquidLibrary.xml' is denied.
>
> So the file is in the correct location (as far as I am aware) and we are
> trying to access it at the correct location, yet we are denied? Why?
>
>
> "Wayne Hartell" <w.hartell@ozemail.com.au> wrote in message
>> This has probably been asked before but I'm running out of time to get an
>> answer and my initial search turned up empty.
>>
>> We have an application that runs as a stand alone application and also a
>> hosted "module" of 3rd party applications. We have found just recently
>> that one of our 3rd party host applications is certified on Vista and
>> seeing our Stand Alone application works on Vista (after getting past a
>> couple of curly issues; at least one MS bug in there) we want to also
>> support our application running as a module in the 3rd party app.
>>
>> Problem that we are experiencing is that the 3rd party has done whatever
>> they need to do in terms of the manifest or what have you to indicate
>> that their application is Vista aware. This of course turns of file
>> system virtualization and we are running into a couple of issues when
>> running under that environment. The main issue is that I am finding our
>> application cannot access certain files that it should be able to access.
>> We are basically getting errors saying we cannot access the data in our
>> company folder under (C:\ProgramData\All Users\<Company
>> Name>\<Application Name>\). But hold on I thought, isn't this location
>> the "correct" location for application data that is shared between users?
>> Then I thought that maybe our code is getting to this location through
>> virtualization and seeing it is turned off now we hit the problem. So I
>> tracked down the code and it seems we are doing the right thing, or what
>> I at least expected to be the right thing... we are using....
>>
>> Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
>> Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
>> Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
>> Environment.GetFolderPath(Environment.SpecialFolder.Personal)
>>
>> to build up all of our working directories.
>>
>> So why is this giving us grief on Vista? Isn't this the recommended
>> practice? Seems like the first one on the list is giving us grief and I
>> am reading that this is supposed to be for roaming profiles. Maybe that
>> is the issue?
>>
>> Please help, or let me know if any additional information is required....
>>
>
>

Pretty active group this... I'm talking to myself.

I think I'm resigned to the fact that if we want a folder under
C:\ProgramData\ under Vista we had better be creating those folders and
setting the security at deployment time when we have admin rights (if that's
even possible).

The joys of Vista....


"Wayne Hartell" <w.hartell@ozemail.com.au> wrote in message
news:OGxIDWPQHHA.2340@TK2MSFTNGP05.phx.gbl...
> Yet more investigation and I am pretty sure that this folder is the
> problem...
>
> Environment.SpecialFolder.CommonApplicationData
>
> Under XP this is:
> C:\Documents and Settings\All Users\Application Data
>
> Under Vista this is:
> C:\ProgramData\
>
> The problem is under Vista this folder is not writeable unless running as
> as admin!!! What the? WHERE do we store application data that is shared
> between users then????????????????? SpecialFolder.ApplicationData,
> LocalApplicationData are both user specific!
>
> I have to missing something right????
>
>
> "Wayne Hartell" <w.hartell@ozemail.com.au> wrote in message
> news:u8DZaxOQHHA.3960@TK2MSFTNGP05.phx.gbl...
>> Actually I have Vista open now and the location the starting files are
>> deployed to is:
>>
>> C:\ProgramData\<Company Name>\<Application Name>\<SubFolder>\<SubFolder>\
>>
>> not...
>>
>> C:\ProgramData\All Users\<Company Name>\<Application Name>\
>>
>> which I think is correct, and here is the exception...
>>
>> System.UnauthorizedAccessException: Access to the path
>> 'C:\ProgramData\<Company Name>\<Product
>> Name>\8\Libraries\LiquidLibrary.xml' is denied.
>>
>> So the file is in the correct location (as far as I am aware) and we are
>> trying to access it at the correct location, yet we are denied? Why?
>>
>>
>> "Wayne Hartell" <w.hartell@ozemail.com.au> wrote in message
>>> This has probably been asked before but I'm running out of time to get
>>> an answer and my initial search turned up empty.
>>>
>>> We have an application that runs as a stand alone application and also a
>>> hosted "module" of 3rd party applications. We have found just recently
>>> that one of our 3rd party host applications is certified on Vista and
>>> seeing our Stand Alone application works on Vista (after getting past a
>>> couple of curly issues; at least one MS bug in there) we want to also
>>> support our application running as a module in the 3rd party app.
>>>
>>> Problem that we are experiencing is that the 3rd party has done whatever
>>> they need to do in terms of the manifest or what have you to indicate
>>> that their application is Vista aware. This of course turns of file
>>> system virtualization and we are running into a couple of issues when
>>> running under that environment. The main issue is that I am finding our
>>> application cannot access certain files that it should be able to
>>> access. We are basically getting errors saying we cannot access the data
>>> in our company folder under (C:\ProgramData\All Users\<Company
>>> Name>\<Application Name>\). But hold on I thought, isn't this location
>>> the "correct" location for application data that is shared between
>>> users? Then I thought that maybe our code is getting to this location
>>> through virtualization and seeing it is turned off now we hit the
>>> problem. So I tracked down the code and it seems we are doing the right
>>> thing, or what I at least expected to be the right thing... we are
>>> using....
>>>
>>> Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
>>> Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
>>> Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
>>> Environment.GetFolderPath(Environment.SpecialFolder.Personal)
>>>
>>> to build up all of our working directories.
>>>
>>> So why is this giving us grief on Vista? Isn't this the recommended
>>> practice? Seems like the first one on the list is giving us grief and I
>>> am reading that this is supposed to be for roaming profiles. Maybe that
>>> is the issue?
>>>
>>> Please help, or let me know if any additional information is
>>> required....
>>>
>>
>>
>
>

Hello,

Vista is set up such that files saved from one user's account cannot be
modified from another user's account. This enforces isolation between one
user account and another, as well as protects settings/files that affect the
state of the entire system.

Your program should indeed install whatever machine-wide state it needs in
ProgramData at install time - this folder is shared between all user
accounts; however, it is a read-only type of shared . Administrator
privileges are needed to modify these files if the current user did not
create them because they affect the entire computer, not just the current
user account.

In accordance with this policy, the security on the ProgramData folder is as
follows:

System: Full Control over files & folders
Administrators: Full Control over files & folders
Creator/Owner: Full Control over files & folders
Users: Read Only for files, but can create new folders and files

What this accomplishes is that it allows any user to read and create a
folder/file anywhere inside the ProgramData folder, but the user can only
modify the files that were created from their user account; they cannot
modify files created from another user account.

The only exception that I know of to this policy is the c:\users\public
folder, which is designed to allow users to store documents and such that
they want to be world read/writable.


--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

Hi Jimmy,

Thanks for the explanation.

Do you know if there is any way to obtain the C:\Users\Public\ folder
location through the SpecialFolder APIs or is this just something specific
to Vista that doesn't have an associated API?

Either way I think the best solution for my company's application is to
simply store the data in a user specific location (for some reason we store
information in three different places (local, roaming, shared) - I'm not the
one who designed it that way!) as I don't think there is any real need to
make the data available machine wide other than it would have been "nice" to
share between users on the same machine.

Regards,
Wayne.


"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in message
news:88E25EE5-6FCF-46DA-A697-B33E2885D9DA@microsoft.com...
> Hello,
>
> Vista is set up such that files saved from one user's account cannot be
> modified from another user's account. This enforces isolation between one
> user account and another, as well as protects settings/files that affect
> the state of the entire system.
>
> Your program should indeed install whatever machine-wide state it needs in
> ProgramData at install time - this folder is shared between all user
> accounts; however, it is a read-only type of shared . Administrator
> privileges are needed to modify these files if the current user did not
> create them because they affect the entire computer, not just the current
> user account.
>
> In accordance with this policy, the security on the ProgramData folder is
> as follows:
>
> System: Full Control over files & folders
> Administrators: Full Control over files & folders
> Creator/Owner: Full Control over files & folders
> Users: Read Only for files, but can create new folders and files
>
> What this accomplishes is that it allows any user to read and create a
> folder/file anywhere inside the ProgramData folder, but the user can only
> modify the files that were created from their user account; they cannot
> modify files created from another user account.
>
> The only exception that I know of to this policy is the c:\users\public
> folder, which is designed to allow users to store documents and such that
> they want to be world read/writable.
>
>
> --
> - JB
> Microsoft MVP - Windows Shell/User
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/

<snip>
> Hi Jimmy,
>
> Thanks for the explanation.

You're welcome

> Do you know if there is any way to obtain the C:\Users\Public\ folder
> location through the SpecialFolder APIs or is this just something specific
> to Vista that doesn't have an associated API?

C:\users\public\ roughly corresponds to c:\documents and settings\all
users\, so you can use some of the CSIDL_COMMON_* idl's to get in there, for
instance:

CSIDL_COMMON_DOCUMENTS
CSIDL_COMMON_MUSIC
CSIDL_COMMON_PICTURES
CSIDL_COMMON_VIDEO

I don't think there's a way to just get the root "common" folder. Which is
kind of a good thing, I guess, since the common folder in Vista is split up
into a bunch of different folders, as compared to XP.

> Either way I think the best solution for my company's application is to
> simply store the data in a user specific location

I agree .

> (for some reason we store information in three different places (local,
> roaming, shared) - I'm not the one who designed it that way!) as I don't
> think there is any real need to make the data available machine wide other
> than it would have been "nice" to share between users on the same machine.

Yeah, it is kind of a pain to follow all of these little programming rules
in the name of security. However, we've seen what happens when these kind of
rules aren't enforced (the culmination of the Windows 9x product line).

> Regards,
> Wayne.



--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/