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.SpecialFolde r.ApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.LocalApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.CommonApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.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" 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.SpecialFolde r.ApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.LocalApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.CommonApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.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" wrote in message
...
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" 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.SpecialFolde r.ApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.LocalApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.CommonApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.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" wrote in message
...
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" wrote in message
...
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" 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.SpecialFolde r.ApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.LocalApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.CommonApplicationData)
Environment.GetFolderPath(Environment.SpecialFolde r.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" wrote in message
...
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/