Manifest File - Installs in Vista

R

rick allison

I'm out of my league on this one. And I don't know if this is the right
newsgroup, but here goes.

Access 2000, 2002, 2003, and 2007.

I distribute a front-end (.mde), back-end (.mdb), an ini file, a help file,
and a readme file. That's it.

Before Vista I used InstallShield and put everything in c:\program files\my
application. Life was good. I was able to install once and use winzip to
install updates and fixes. Of course everything is in the .mde file.

Along comes Vista and all hell breaks loose. Guess I shouldn't have been
putting the FE and BE in program files and now Vista enforces that.

So, I want to install in Vista but run into this Virtual Store issue because
I don't have a Manifest file.

The question - does MS Access deal well with a Manifest file? Can anyone
provide advice to me on this?

All I want to do is install my application is Vista and have a way to
provide updates to it. Sigh

Vista is causing me a lot of grief.

Thanks,

Rick
 
T

Tony Toews [MVP]

rick allison said:
I'm out of my league on this one. And I don't know if this is the right
newsgroup, but here goes.

Close enough.
Before Vista I used InstallShield and put everything in c:\program files\my
application. Life was good. I was able to install once and use winzip to
install updates and fixes. Of course everything is in the .mde file.

Along comes Vista and all hell breaks loose. Guess I shouldn't have been
putting the FE and BE in program files and now Vista enforces that.

Correct. We should've been using folders such as %appdata% for the FE
and My Documents\AppName for the BE MDB. Or possibly a folder right
off C drive but I'm not a fan of that. Might as well use MS
suggestions.
So, I want to install in Vista but run into this Virtual Store issue because
I don't have a Manifest file.

Now that puzzles me. Hmm, I think the manifest file might be because
you are running an older copy of InstallShield which doesn't have the
manifest file.

Also how are you distributing the Access runtime?

FWIW Albert Kallal has done a lot of work with the free Inno
installer. It's working real nice for me.

Sample inno script which checks to see if a version of Access is
installed. If not it tells you to install a runtime version of
Access. If installed then it continues to install your FE MDE and
other assorted files.'
http://groups.google.com/group/microsoft.public.access/msg/10e3fc9234660872?hl=en

Sample inno script which "wraps" the package wizard install into a
single .exe
http://groups.google.com/group/comp.databases.ms-access/msg/4aa1b33a191bf1f8?hl=en

Tony
 
T

Tony Toews [MVP]

rick allison said:
I'm out of my league on this one. And I don't know if this is the right
newsgroup, but here goes.

Close enough.
Before Vista I used InstallShield and put everything in c:\program files\my
application. Life was good. I was able to install once and use winzip to
install updates and fixes. Of course everything is in the .mde file.

Along comes Vista and all hell breaks loose. Guess I shouldn't have been
putting the FE and BE in program files and now Vista enforces that.

Correct. We should've been using folders such as %appdata% for the FE
and My Documents\AppName for the BE MDB. Or possibly a folder right
off C drive but I'm not a fan of that. Might as well use MS
suggestions.
So, I want to install in Vista but run into this Virtual Store issue because
I don't have a Manifest file.

Now that puzzles me. Hmm, I think the manifest file might be because
you are running an older copy of InstallShield which doesn't have the
manifest file.

Also how are you distributing the Access runtime?

FWIW Albert Kallal has done a lot of work with the free Inno
installer. It's working real nice for me.

Sample inno script which checks to see if a version of Access is
installed. If not it tells you to install a runtime version of
Access. If installed then it continues to install your FE MDE and
other assorted files.'
http://groups.google.com/group/microsoft.public.access/msg/10e3fc9234660872?hl=en

Sample inno script which "wraps" the package wizard install into a
single .exe
http://groups.google.com/group/comp.databases.ms-access/msg/4aa1b33a191bf1f8?hl=en

Tony
 
G

Graham Mandeno

Hi Rick

Yes, I remember when life was good :)

With Vista, unless you run "as Administrator" (even if you ARE an
Administrator) there are certain areas that get "virtualised". This means
that, even though you would normally have the rights to modify objects in
these areas, if you try to modify them then you will create your own
"personal" copies of them.

Areas that are virtualised include:
C:\Windows
C:\Program Files
C:\ProgramData (formerly C:\Document and Settings\All Users\AppData)
HKEY_LOCAL_MACHINE in the registry

What I *used* to do was install the "read only" things (front-end, help,
readme, etc) in C:\Program Files\Application and the "changeable" things
(back-end, ini file, etc) in All Users\AppData.

However, with Vista it all turned to custard.

Because an Access file (even an MDE) gets "modified" whenever you open it,
the front-end got copied into some black hole accessible only to the current
user. Imagine my surprise when a new version was installed "as
Administrator" and the old version was still the one that opened!

The back-end also got virtualised, so different users on the same machine
created their own copies - which somewhat defeats the purpose of a back-end!

So now, I have reverted to good old DOS days and I install everything in a
folder that Windows knows nothing about and therefore cannot tamper with.

Anything that used to go in Program Files\... goes in C:\Applications\...

Anything that is specific to the current user (temp files, etc) goes in
C:\Users\<Current user>\AppData

Anything that is truly shared (like the back-end) usually goes in a network
share.

HTH!
 
G

Graham Mandeno

Hi Rick

Yes, I remember when life was good :)

With Vista, unless you run "as Administrator" (even if you ARE an
Administrator) there are certain areas that get "virtualised". This means
that, even though you would normally have the rights to modify objects in
these areas, if you try to modify them then you will create your own
"personal" copies of them.

Areas that are virtualised include:
C:\Windows
C:\Program Files
C:\ProgramData (formerly C:\Document and Settings\All Users\AppData)
HKEY_LOCAL_MACHINE in the registry

What I *used* to do was install the "read only" things (front-end, help,
readme, etc) in C:\Program Files\Application and the "changeable" things
(back-end, ini file, etc) in All Users\AppData.

However, with Vista it all turned to custard.

Because an Access file (even an MDE) gets "modified" whenever you open it,
the front-end got copied into some black hole accessible only to the current
user. Imagine my surprise when a new version was installed "as
Administrator" and the old version was still the one that opened!

The back-end also got virtualised, so different users on the same machine
created their own copies - which somewhat defeats the purpose of a back-end!

So now, I have reverted to good old DOS days and I install everything in a
folder that Windows knows nothing about and therefore cannot tamper with.

Anything that used to go in Program Files\... goes in C:\Applications\...

Anything that is specific to the current user (temp files, etc) goes in
C:\Users\<Current user>\AppData

Anything that is truly shared (like the back-end) usually goes in a network
share.

HTH!
 
D

David W. Fenton

Yes, I remember when life was good :)

You mean back when everyone ran as administrator, instead of
correctly running in a user-level logon?
With Vista, unless you run "as Administrator" (even if you ARE an
Administrator) there are certain areas that get "virtualised".

They get virtualized because of security settings that have been
present since Windows 2000. Users have only read access to C:\,
C:\Windows and C:\Program Files. Because Vista changes the way your
logon permissions interact with the security tokens you launch apps
with, this has clinched the deal and forces even administrative
users to recognize that they shouldn't be putting user-writable data
in the folders where users have only Read permission, precisely
because Vista by default runs all process with a user-level security
token even when the user is an administrator (unless you explicitly
instruct Vista to run a particular app with admin permissions).
This means
that, even though you would normally have the rights to modify
objects in these areas,

You never had those rights unless you were running as an
administrator.
if you try to modify them then you will create your own
"personal" copies of them.

Areas that are virtualised include:
C:\Windows
C:\Program Files
C:\ProgramData (formerly C:\Document and Settings\All
Users\AppData) HKEY_LOCAL_MACHINE in the registry

What I *used* to do was install the "read only" things (front-end,
help, readme, etc) in C:\Program Files\Application and the
"changeable" things (back-end, ini file, etc) in All
Users\AppData.

However, with Vista it all turned to custard.

Because an Access file (even an MDE) gets "modified" whenever you
open it, the front-end got copied into some black hole accessible
only to the current user. Imagine my surprise when a new version
was installed "as Administrator" and the old version was still the
one that opened!

I don't know when you first discovered this in Vista, but you should
have been doing things properly as long ago as 1999, when Windows
2000 came out.
The back-end also got virtualised, so different users on the same
machine created their own copies - which somewhat defeats the
purpose of a back-end!

So now, I have reverted to good old DOS days and I install
everything in a folder that Windows knows nothing about and
therefore cannot tamper with.

Anything that used to go in Program Files\... goes in
C:\Applications\...

This is the wrong place, even though it doesn't cause virtualization
problems. It's wrong because you either have to run as an admin to
have write access to this location, or you have to manually assign
write permission for user-level logons.
Anything that is specific to the current user (temp files, etc)
goes in C:\Users\<Current user>\AppData

Anything that is truly shared (like the back-end) usually goes in
a network share.

These latter two are fine.

The reason you ran into problems is because you'd been doing it
wrong for a long time, and you're still doing part of it wrong.
 
D

David W. Fenton

Yes, I remember when life was good :)

You mean back when everyone ran as administrator, instead of
correctly running in a user-level logon?
With Vista, unless you run "as Administrator" (even if you ARE an
Administrator) there are certain areas that get "virtualised".

They get virtualized because of security settings that have been
present since Windows 2000. Users have only read access to C:\,
C:\Windows and C:\Program Files. Because Vista changes the way your
logon permissions interact with the security tokens you launch apps
with, this has clinched the deal and forces even administrative
users to recognize that they shouldn't be putting user-writable data
in the folders where users have only Read permission, precisely
because Vista by default runs all process with a user-level security
token even when the user is an administrator (unless you explicitly
instruct Vista to run a particular app with admin permissions).
This means
that, even though you would normally have the rights to modify
objects in these areas,

You never had those rights unless you were running as an
administrator.
if you try to modify them then you will create your own
"personal" copies of them.

Areas that are virtualised include:
C:\Windows
C:\Program Files
C:\ProgramData (formerly C:\Document and Settings\All
Users\AppData) HKEY_LOCAL_MACHINE in the registry

What I *used* to do was install the "read only" things (front-end,
help, readme, etc) in C:\Program Files\Application and the
"changeable" things (back-end, ini file, etc) in All
Users\AppData.

However, with Vista it all turned to custard.

Because an Access file (even an MDE) gets "modified" whenever you
open it, the front-end got copied into some black hole accessible
only to the current user. Imagine my surprise when a new version
was installed "as Administrator" and the old version was still the
one that opened!

I don't know when you first discovered this in Vista, but you should
have been doing things properly as long ago as 1999, when Windows
2000 came out.
The back-end also got virtualised, so different users on the same
machine created their own copies - which somewhat defeats the
purpose of a back-end!

So now, I have reverted to good old DOS days and I install
everything in a folder that Windows knows nothing about and
therefore cannot tamper with.

Anything that used to go in Program Files\... goes in
C:\Applications\...

This is the wrong place, even though it doesn't cause virtualization
problems. It's wrong because you either have to run as an admin to
have write access to this location, or you have to manually assign
write permission for user-level logons.
Anything that is specific to the current user (temp files, etc)
goes in C:\Users\<Current user>\AppData

Anything that is truly shared (like the back-end) usually goes in
a network share.

These latter two are fine.

The reason you ran into problems is because you'd been doing it
wrong for a long time, and you're still doing part of it wrong.
 
G

Graham Mandeno

Hi David

David W. Fenton said:
You mean back when everyone ran as administrator, instead of
correctly running in a user-level logon?

Yes, I do. It was a joke - hence the smiley :)

Thank you for explaining the reasons for virtualisation in much greater
detail than I bothered to. The fact remains that its introduction caused
confusion and caused certain things to break for some people.
I don't know when you first discovered this in Vista, but you should
have been doing things properly as long ago as 1999, when Windows
2000 came out.

Well, perhaps you're right, but I beg to differ. My understanding of
C:\Program Files was that it was the correct place for admins to install
programs. An Access front-end is arguably a program. It contains no data
and it is used to access and manipulate data. It used to work perfectly
well for an admin to install a front-end in Program Files and a back-end in
a "shared" area where all users of the app (admins or not) had write
access - the obvious candidate on a standalone machine being the
Common_Appdata folder.

This worked well - lowly users and admins alike could open the front-end and
use it, modifying the data in the back-end. The only difference was that
lowly users did not cause the modification date on the front-end to change,
while admins did.

With Vista however, when an admin opened and closed the frontend he created
for himself a new virtualised copy. When he installed an updated version,
he found himself still using the old version.

As for Common_AppData, surely its purpose is for data which is to be shared.
It is up to the owner of that data whether or not users may modify it.
However, with Vista, a user who has legitimate write access to a file in
that location creates a virtualised copy, and the changes cannot be seen by
other users.

Does this seem right? I think not.
This is the wrong place, even though it doesn't cause virtualization
problems. It's wrong because you either have to run as an admin to
have write access to this location, or you have to manually assign
write permission for user-level logons.

I disagree. If a proper installation program (I use Inno Setup) creates
this folder and grants the required read and/or write permissions to the
appropriate user groups, how is this wrong?

I infer that you would have front-ends installed in each user's AppData
folder? For me, this has two problems: (a) it offers no protection to
read-only components that ought not to be tampered with by non-admin users
and (b) it creates a maintenance nightmare - for example, if you have five
different users who regularly use the same workstation, you need to maintaib
five concurrent copies of the same application (front-end and associated
files) on the one computer.

That's my 2c worth.
 
G

Graham Mandeno

Hi David

David W. Fenton said:
You mean back when everyone ran as administrator, instead of
correctly running in a user-level logon?

Yes, I do. It was a joke - hence the smiley :)

Thank you for explaining the reasons for virtualisation in much greater
detail than I bothered to. The fact remains that its introduction caused
confusion and caused certain things to break for some people.
I don't know when you first discovered this in Vista, but you should
have been doing things properly as long ago as 1999, when Windows
2000 came out.

Well, perhaps you're right, but I beg to differ. My understanding of
C:\Program Files was that it was the correct place for admins to install
programs. An Access front-end is arguably a program. It contains no data
and it is used to access and manipulate data. It used to work perfectly
well for an admin to install a front-end in Program Files and a back-end in
a "shared" area where all users of the app (admins or not) had write
access - the obvious candidate on a standalone machine being the
Common_Appdata folder.

This worked well - lowly users and admins alike could open the front-end and
use it, modifying the data in the back-end. The only difference was that
lowly users did not cause the modification date on the front-end to change,
while admins did.

With Vista however, when an admin opened and closed the frontend he created
for himself a new virtualised copy. When he installed an updated version,
he found himself still using the old version.

As for Common_AppData, surely its purpose is for data which is to be shared.
It is up to the owner of that data whether or not users may modify it.
However, with Vista, a user who has legitimate write access to a file in
that location creates a virtualised copy, and the changes cannot be seen by
other users.

Does this seem right? I think not.
This is the wrong place, even though it doesn't cause virtualization
problems. It's wrong because you either have to run as an admin to
have write access to this location, or you have to manually assign
write permission for user-level logons.

I disagree. If a proper installation program (I use Inno Setup) creates
this folder and grants the required read and/or write permissions to the
appropriate user groups, how is this wrong?

I infer that you would have front-ends installed in each user's AppData
folder? For me, this has two problems: (a) it offers no protection to
read-only components that ought not to be tampered with by non-admin users
and (b) it creates a maintenance nightmare - for example, if you have five
different users who regularly use the same workstation, you need to maintaib
five concurrent copies of the same application (front-end and associated
files) on the one computer.

That's my 2c worth.
 
D

David W. Fenton

Yes, I do. It was a joke - hence the smiley :)

Thank you for explaining the reasons for virtualisation in much
greater detail than I bothered to. The fact remains that its
introduction caused confusion and caused certain things to break
for some people.

Yes, indeed it did, but not for those who were operating with
correct user account settings, and an awareness of the default
access settings for the folders in question that have been in place
since Windows 2000.
Well, perhaps you're right, but I beg to differ. My understanding
of C:\Program Files was that it was the correct place for admins
to install programs.

Read-only application files. There were no properly-designed Windows
applications that needed write-only access to C:\Program Files\
after Windows 2000 because user-level logons had only read access to
those folders. This is, of course, why programs like QuickBooks are
so roundly condemned, as they still required (before Vista) that you
ran with elevated permissions -- QuickBooks would not run in a
user-level logon at all (power user was the lowest possible).
An Access front-end is arguably a program.

An EXE file is not writable (well, if it is, then you may be running
a virus), and thus, the fact that it is true that a front end is, in
fact, a program file, it's not like other program files, as it has
to be writable.
It contains no data
and it is used to access and manipulate data. It used to work
perfectly well for an admin to install a front-end in Program
Files and a back-end in a "shared" area where all users of the app
(admins or not) had write access - the obvious candidate on a
standalone machine being the Common_Appdata folder.

I don't recognize that folder, i.e., "Common_Appdata". So far as I
can see this is a Windows Vista environment variable, as it doesn't
exist in WinXP or before, and all the Googling I've done seems to
refer to Vista.

Regardless of the correct location in Vista for application data for
actual applications, the only place for an Access front end is), is
somewhere in the All Users folder, since that is, by definition,
read/write for all users.
This worked well - lowly users and admins alike could open the
front-end and use it, modifying the data in the back-end. The
only difference was that lowly users did not cause the
modification date on the front-end to change, while admins did.

Your explanation makes little sense to me, but I don't use Vista.
You seem to be saying that before Vista, Common_Appdata (which
didn't exist before Vista) was the place to store writable
application data. That is not true in WinXP and before -- instead
the location was:

%ALLUSERSPROFILE%\Application Data\
With Vista however, when an admin opened and closed the frontend
he created for himself a new virtualised copy. When he installed
an updated version, he found himself still using the old version.

As for Common_AppData, surely its purpose is for data which is to
be shared.

This is all about permissions on the folders involved. If
%Common_AppData% points to a folder that does not give users write
access, then it's clearly not the right place to put an Access front
end, regardless of what the rules are for application data
locations.
It is up to the owner of that data whether or not users may modify
it. However, with Vista, a user who has legitimate write access to
a file in that location creates a virtualised copy, and the
changes cannot be seen by other users.

Does this seem right? I think not.

It's different. If you avoid the virtualized folders you won't have
an issue.
I disagree. If a proper installation program (I use Inno Setup)
creates this folder and grants the required read and/or write
permissions to the appropriate user groups, how is this wrong?

If it doesn't work?
I infer that you would have front-ends installed in each user's
AppData folder?

In the All Users folder.
For me, this has two problems: (a) it offers no
protection to read-only components that ought not to be tampered
with by non-admin users and (b) it creates a maintenance nightmare
- for example, if you have five different users who regularly use
the same workstation, you need to maintaib five concurrent copies
of the same application (front-end and associated files) on the
one computer.

How is this a disaster? Even if you have a 1GB front end, that's
only 5 GBs. How much of the hard drive is that, percentagewise? Even
my 4-year-old laptop that wasn't every heavily provisioned to begin
with has plenty of room for multiple copies of such an outsized
front end (and it's unrealistic to believe that anyone is deploying
front ends over 100MBs, in my opinion).
 
D

David W. Fenton

Yes, I do. It was a joke - hence the smiley :)

Thank you for explaining the reasons for virtualisation in much
greater detail than I bothered to. The fact remains that its
introduction caused confusion and caused certain things to break
for some people.

Yes, indeed it did, but not for those who were operating with
correct user account settings, and an awareness of the default
access settings for the folders in question that have been in place
since Windows 2000.
Well, perhaps you're right, but I beg to differ. My understanding
of C:\Program Files was that it was the correct place for admins
to install programs.

Read-only application files. There were no properly-designed Windows
applications that needed write-only access to C:\Program Files\
after Windows 2000 because user-level logons had only read access to
those folders. This is, of course, why programs like QuickBooks are
so roundly condemned, as they still required (before Vista) that you
ran with elevated permissions -- QuickBooks would not run in a
user-level logon at all (power user was the lowest possible).
An Access front-end is arguably a program.

An EXE file is not writable (well, if it is, then you may be running
a virus), and thus, the fact that it is true that a front end is, in
fact, a program file, it's not like other program files, as it has
to be writable.
It contains no data
and it is used to access and manipulate data. It used to work
perfectly well for an admin to install a front-end in Program
Files and a back-end in a "shared" area where all users of the app
(admins or not) had write access - the obvious candidate on a
standalone machine being the Common_Appdata folder.

I don't recognize that folder, i.e., "Common_Appdata". So far as I
can see this is a Windows Vista environment variable, as it doesn't
exist in WinXP or before, and all the Googling I've done seems to
refer to Vista.

Regardless of the correct location in Vista for application data for
actual applications, the only place for an Access front end is), is
somewhere in the All Users folder, since that is, by definition,
read/write for all users.
This worked well - lowly users and admins alike could open the
front-end and use it, modifying the data in the back-end. The
only difference was that lowly users did not cause the
modification date on the front-end to change, while admins did.

Your explanation makes little sense to me, but I don't use Vista.
You seem to be saying that before Vista, Common_Appdata (which
didn't exist before Vista) was the place to store writable
application data. That is not true in WinXP and before -- instead
the location was:

%ALLUSERSPROFILE%\Application Data\
With Vista however, when an admin opened and closed the frontend
he created for himself a new virtualised copy. When he installed
an updated version, he found himself still using the old version.

As for Common_AppData, surely its purpose is for data which is to
be shared.

This is all about permissions on the folders involved. If
%Common_AppData% points to a folder that does not give users write
access, then it's clearly not the right place to put an Access front
end, regardless of what the rules are for application data
locations.
It is up to the owner of that data whether or not users may modify
it. However, with Vista, a user who has legitimate write access to
a file in that location creates a virtualised copy, and the
changes cannot be seen by other users.

Does this seem right? I think not.

It's different. If you avoid the virtualized folders you won't have
an issue.
I disagree. If a proper installation program (I use Inno Setup)
creates this folder and grants the required read and/or write
permissions to the appropriate user groups, how is this wrong?

If it doesn't work?
I infer that you would have front-ends installed in each user's
AppData folder?

In the All Users folder.
For me, this has two problems: (a) it offers no
protection to read-only components that ought not to be tampered
with by non-admin users and (b) it creates a maintenance nightmare
- for example, if you have five different users who regularly use
the same workstation, you need to maintaib five concurrent copies
of the same application (front-end and associated files) on the
one computer.

How is this a disaster? Even if you have a 1GB front end, that's
only 5 GBs. How much of the hard drive is that, percentagewise? Even
my 4-year-old laptop that wasn't every heavily provisioned to begin
with has plenty of room for multiple copies of such an outsized
front end (and it's unrealistic to believe that anyone is deploying
front ends over 100MBs, in my opinion).
 
G

Graham Mandeno

Hi David

[heavily snipped]
I don't recognize that folder, i.e., "Common_Appdata". So far as I
can see this is a Windows Vista environment variable, as it doesn't
exist in WinXP or before, and all the Googling I've done seems to
refer to Vista.

I'm very sorry, I wasn't clear with my terminology.

By "COMMON_APPDATA" I was abbreviating "CSIDL_COMMON_APPDATA", the name of
the constant by which the SHGetSpecialFolderPath API returns the path to the
common application data folder.

On Windows XP this returns:
C:\Documents and Settings\All Users\Application Data

On Vista it returns:
C:\ProgramData

At http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx MSDN says:
<quote>
CSIDL_COMMON_APPDATA: The file system directory that contains application
data for all users. A typical path is C:\Documents and Settings\All
Users\Application Data. This folder is used for application data that is not
user specific. For example, an application can store a spell-check
dictionary, a database of clip art, or a log file in the
CSIDL_COMMON_APPDATA folder. This information will not roam and is available
to anyone using the computer.
<\quote>

There is nothing here that suggests that data in this folder should be
read-only, nor user-specific. In fact it implies that it should be writable
("spell-check dictionary", "log file") and states that it is NOT
user-specific ("for all users").

However, Vista has effectively made it read-only AND user-specific because,
even though you can write to data there, if you do so when not running "as
Administrator" then your copy of the file will be virtualised and no one
else will get to see it. Furthermore, if the "real" copy is modified or
replaced, you will be oblivious to the fact and will continue to use your
own copy.
Regardless of the correct location in Vista for application data for
actual applications, the only place for an Access front end is), is
somewhere in the All Users folder, since that is, by definition,
read/write for all users.

But you see, it is NOT any more.

Under Vista, C:\Documents and Settings has been replaced by C:\Users. This
folder contains (for some semblance of backward compatibility only) a
shortcut named "All Users". This shortcut points to... you guessed it...
C:\ProgramData!
Your explanation makes little sense to me, but I don't use Vista.
You seem to be saying that before Vista, Common_Appdata (which
didn't exist before Vista) was the place to store writable
application data. That is not true in WinXP and before -- instead
the location was:

%ALLUSERSPROFILE%\Application Data\

The fact that you don't use Vista explains the confusion, and I hope it
makes sense now. As you can see now, COMMON_APPDATA *did* exist before
Vista, only now its nature has changed.

You say your practice is to install a front-ends and associated files in the
All Users folder. I would seriously rethink that if I were you :)
 
G

Graham Mandeno

Hi David

[heavily snipped]
I don't recognize that folder, i.e., "Common_Appdata". So far as I
can see this is a Windows Vista environment variable, as it doesn't
exist in WinXP or before, and all the Googling I've done seems to
refer to Vista.

I'm very sorry, I wasn't clear with my terminology.

By "COMMON_APPDATA" I was abbreviating "CSIDL_COMMON_APPDATA", the name of
the constant by which the SHGetSpecialFolderPath API returns the path to the
common application data folder.

On Windows XP this returns:
C:\Documents and Settings\All Users\Application Data

On Vista it returns:
C:\ProgramData

At http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx MSDN says:
<quote>
CSIDL_COMMON_APPDATA: The file system directory that contains application
data for all users. A typical path is C:\Documents and Settings\All
Users\Application Data. This folder is used for application data that is not
user specific. For example, an application can store a spell-check
dictionary, a database of clip art, or a log file in the
CSIDL_COMMON_APPDATA folder. This information will not roam and is available
to anyone using the computer.
<\quote>

There is nothing here that suggests that data in this folder should be
read-only, nor user-specific. In fact it implies that it should be writable
("spell-check dictionary", "log file") and states that it is NOT
user-specific ("for all users").

However, Vista has effectively made it read-only AND user-specific because,
even though you can write to data there, if you do so when not running "as
Administrator" then your copy of the file will be virtualised and no one
else will get to see it. Furthermore, if the "real" copy is modified or
replaced, you will be oblivious to the fact and will continue to use your
own copy.
Regardless of the correct location in Vista for application data for
actual applications, the only place for an Access front end is), is
somewhere in the All Users folder, since that is, by definition,
read/write for all users.

But you see, it is NOT any more.

Under Vista, C:\Documents and Settings has been replaced by C:\Users. This
folder contains (for some semblance of backward compatibility only) a
shortcut named "All Users". This shortcut points to... you guessed it...
C:\ProgramData!
Your explanation makes little sense to me, but I don't use Vista.
You seem to be saying that before Vista, Common_Appdata (which
didn't exist before Vista) was the place to store writable
application data. That is not true in WinXP and before -- instead
the location was:

%ALLUSERSPROFILE%\Application Data\

The fact that you don't use Vista explains the confusion, and I hope it
makes sense now. As you can see now, COMMON_APPDATA *did* exist before
Vista, only now its nature has changed.

You say your practice is to install a front-ends and associated files in the
All Users folder. I would seriously rethink that if I were you :)
 
D

David W. Fenton

Under Vista, C:\Documents and Settings has been replaced by
C:\Users. This folder contains (for some semblance of backward
compatibility only) a shortcut named "All Users". This shortcut
points to... you guessed it... C:\ProgramData!

Well, OK, that's a change of structure after all. My understanding
since Windows 2000 was that the %ALLUSERSPROFILE%\Application Data\
was the place that apps were supposed to write their changeable data
that is not user-specific, and that user-specific changeable data
belonded in the user's AppData folder.

However, I must say that this passage you quoted:

At http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx MSDN
says: <quote>
CSIDL_COMMON_APPDATA: The file system directory that contains
application data for all users. A typical path is C:\Documents and
Settings\All Users\Application Data. This folder is used for
application data that is not user specific. For example, an
application can store a spell-check dictionary, a database of clip
art, or a log file in the CSIDL_COMMON_APPDATA folder. This
information will not roam and is available to anyone using the
computer. <\quote>

....implies to me that the data stored there even for previous
versions of Windows should be read-only. A spell-check dictionary is
not actually written to, only the user's custom dictionary, and that
would be stored in the user's AppData folder. All of the rest are
read-only files (once the app is installed), so if you were
following that approach, you'd be OK.

The problem really is that Access has to have write access to the
front end. There's no way around that, and I think it's therefore
necessary to never share the front end on a single workstation
(which is not something that's going to happen that often in most of
the circumstances I've ever worked).

Thanks for clarifying. I think that, based on the quotation, MS has
been consistent, even though so far as I can tell, they've changed
the permissions on %ALLUSERSPROFILE%\Application Data\, which, I
believe give full permissions to the EVERYONE group (that's the way
it is on this WinXP laptop of mine, and I'm pretty sure those are
the default permissions because I never use the EVERYONE group in
setting my own permissions except for shared printers, preferring
the AUTHENTICATED USERS group).

Access is the odd man out here, seems to me, simply because of the
idiosyncratic way in which it uses its "program file."
 
D

David W. Fenton

Under Vista, C:\Documents and Settings has been replaced by
C:\Users. This folder contains (for some semblance of backward
compatibility only) a shortcut named "All Users". This shortcut
points to... you guessed it... C:\ProgramData!

Well, OK, that's a change of structure after all. My understanding
since Windows 2000 was that the %ALLUSERSPROFILE%\Application Data\
was the place that apps were supposed to write their changeable data
that is not user-specific, and that user-specific changeable data
belonded in the user's AppData folder.

However, I must say that this passage you quoted:

At http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx MSDN
says: <quote>
CSIDL_COMMON_APPDATA: The file system directory that contains
application data for all users. A typical path is C:\Documents and
Settings\All Users\Application Data. This folder is used for
application data that is not user specific. For example, an
application can store a spell-check dictionary, a database of clip
art, or a log file in the CSIDL_COMMON_APPDATA folder. This
information will not roam and is available to anyone using the
computer. <\quote>

....implies to me that the data stored there even for previous
versions of Windows should be read-only. A spell-check dictionary is
not actually written to, only the user's custom dictionary, and that
would be stored in the user's AppData folder. All of the rest are
read-only files (once the app is installed), so if you were
following that approach, you'd be OK.

The problem really is that Access has to have write access to the
front end. There's no way around that, and I think it's therefore
necessary to never share the front end on a single workstation
(which is not something that's going to happen that often in most of
the circumstances I've ever worked).

Thanks for clarifying. I think that, based on the quotation, MS has
been consistent, even though so far as I can tell, they've changed
the permissions on %ALLUSERSPROFILE%\Application Data\, which, I
believe give full permissions to the EVERYONE group (that's the way
it is on this WinXP laptop of mine, and I'm pretty sure those are
the default permissions because I never use the EVERYONE group in
setting my own permissions except for shared printers, preferring
the AUTHENTICATED USERS group).

Access is the odd man out here, seems to me, simply because of the
idiosyncratic way in which it uses its "program file."
 
G

Graham Mandeno

Hi David
Thanks for clarifying. I think that, based on the quotation, MS has
been consistent, even though so far as I can tell, they've changed
the permissions on %ALLUSERSPROFILE%\Application Data\, which, I
believe give full permissions to the EVERYONE group (that's the way
it is on this WinXP laptop of mine, and I'm pretty sure those are
the default permissions because I never use the EVERYONE group in
setting my own permissions except for shared printers, preferring
the AUTHENTICATED USERS group).

You're welcome! I'm honoured to have been able to teach you something new
:)

Although, I still believe the quote from MSDN implies general write access.
You may be right about a shared spelling dictionary (arguable) but I fail to
see how a "log file" can be intended to be anything but writeable!

And, the security settings ("Full control" for "Everyone") also strongly
imply that intention.
The problem really is that Access has to have write access to the
front end. There's no way around that, and I think it's therefore
necessary to never share the front end on a single workstation
(which is not something that's going to happen that often in most of
the circumstances I've ever worked).

Yes, I certainly agree with you there! But then again, a front-end in a
read-only area has always been able to be opened without a problem, so it is
not an absolute requirement that it be writeable. The problem comes when
somebody who *does* happen to have write access gets a new, invisible copy
of it that can't easily be overwritten.

BTW, I have two or three clients who have several users sharing the same
workstation - maybe because of shift work, or because different people need
to work in the same area at different times.
 
G

Graham Mandeno

Hi David
Thanks for clarifying. I think that, based on the quotation, MS has
been consistent, even though so far as I can tell, they've changed
the permissions on %ALLUSERSPROFILE%\Application Data\, which, I
believe give full permissions to the EVERYONE group (that's the way
it is on this WinXP laptop of mine, and I'm pretty sure those are
the default permissions because I never use the EVERYONE group in
setting my own permissions except for shared printers, preferring
the AUTHENTICATED USERS group).

You're welcome! I'm honoured to have been able to teach you something new
:)

Although, I still believe the quote from MSDN implies general write access.
You may be right about a shared spelling dictionary (arguable) but I fail to
see how a "log file" can be intended to be anything but writeable!

And, the security settings ("Full control" for "Everyone") also strongly
imply that intention.
The problem really is that Access has to have write access to the
front end. There's no way around that, and I think it's therefore
necessary to never share the front end on a single workstation
(which is not something that's going to happen that often in most of
the circumstances I've ever worked).

Yes, I certainly agree with you there! But then again, a front-end in a
read-only area has always been able to be opened without a problem, so it is
not an absolute requirement that it be writeable. The problem comes when
somebody who *does* happen to have write access gets a new, invisible copy
of it that can't easily be overwritten.

BTW, I have two or three clients who have several users sharing the same
workstation - maybe because of shift work, or because different people need
to work in the same area at different times.
 
T

Tony Toews [MVP]

David W. Fenton said:
However, I must say that this passage you quoted:

At http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx MSDN
says: <quote>
CSIDL_COMMON_APPDATA: The file system directory that contains
application data for all users. A typical path is C:\Documents and
Settings\All Users\Application Data. This folder is used for
application data that is not user specific. For example, an
application can store a spell-check dictionary, a database of clip
art, or a log file in the CSIDL_COMMON_APPDATA folder. This
information will not roam and is available to anyone using the
computer. <\quote>

...implies to me that the data stored there even for previous
versions of Windows should be read-only. A spell-check dictionary is
not actually written to, only the user's custom dictionary, and that
would be stored in the user's AppData folder. All of the rest are
read-only files (once the app is installed), so if you were
following that approach, you'd be OK.

The problem really is that Access has to have write access to the
front end. There's no way around that, and I think it's therefore
necessary to never share the front end on a single workstation
(which is not something that's going to happen that often in most of
the circumstances I've ever worked).

Thanks for clarifying. I think that, based on the quotation, MS has
been consistent, even though so far as I can tell, they've changed
the permissions on %ALLUSERSPROFILE%\Application Data\, which, I
believe give full permissions to the EVERYONE group (that's the way
it is on this WinXP laptop of mine, and I'm pretty sure those are
the default permissions because I never use the EVERYONE group in
setting my own permissions except for shared printers, preferring
the AUTHENTICATED USERS group).

I have an error message in the Auto FE Updater if the user attempts to
create shortcuts in the All Users >> Start Menu >> Programs in Vista
because that particular folder is no longer updatable by users. In Win
XP and previous a user could update/create entries in that folder.

I didn't bother investigating other folders such as the All Users App
Data folder.

Tony
 
T

Tony Toews [MVP]

David W. Fenton said:
However, I must say that this passage you quoted:

At http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx MSDN
says: <quote>
CSIDL_COMMON_APPDATA: The file system directory that contains
application data for all users. A typical path is C:\Documents and
Settings\All Users\Application Data. This folder is used for
application data that is not user specific. For example, an
application can store a spell-check dictionary, a database of clip
art, or a log file in the CSIDL_COMMON_APPDATA folder. This
information will not roam and is available to anyone using the
computer. <\quote>

...implies to me that the data stored there even for previous
versions of Windows should be read-only. A spell-check dictionary is
not actually written to, only the user's custom dictionary, and that
would be stored in the user's AppData folder. All of the rest are
read-only files (once the app is installed), so if you were
following that approach, you'd be OK.

The problem really is that Access has to have write access to the
front end. There's no way around that, and I think it's therefore
necessary to never share the front end on a single workstation
(which is not something that's going to happen that often in most of
the circumstances I've ever worked).

Thanks for clarifying. I think that, based on the quotation, MS has
been consistent, even though so far as I can tell, they've changed
the permissions on %ALLUSERSPROFILE%\Application Data\, which, I
believe give full permissions to the EVERYONE group (that's the way
it is on this WinXP laptop of mine, and I'm pretty sure those are
the default permissions because I never use the EVERYONE group in
setting my own permissions except for shared printers, preferring
the AUTHENTICATED USERS group).

I have an error message in the Auto FE Updater if the user attempts to
create shortcuts in the All Users >> Start Menu >> Programs in Vista
because that particular folder is no longer updatable by users. In Win
XP and previous a user could update/create entries in that folder.

I didn't bother investigating other folders such as the All Users App
Data folder.

Tony
 
T

Tony Toews [MVP]

Graham Mandeno said:
Anything that used to go in Program Files\... goes in C:\Applications\...

Anything that is specific to the current user (temp files, etc) goes in
C:\Users\<Current user>\AppData

Whereas I'm now putting the FE and associated DLL files in
%appdata%\<app name>. (In Vista - C:\Users\<Current user>\AppData\<app
name>.)

The BE goes into My Documents\<app name>.

Now if multiple users are using the same PC then they will have to
re-install the FE and associated DLLs. And the backend will have to
go somewhere else. That's fine by me as that's easy to handle. And
the My Documents folder has an icon so it's real easy to find.
Anything that is truly shared (like the back-end) usually goes in a network
share.

My apps are sometimes installed on stand alone systems. So if the
user then tells me they are using a network I just tell them to grab
the contents of My Documents\<app name> and put it on the network
share. Then they just relink and they're done.

Tony
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Top