Vista - User Directory
DanB
Hi,
This has been a real fight for me and I want to get it right before the
next release.
From the xp days I have a user settings folder, path:
C:\Documents and Settings\All Users\Application Data\Reserve Analyst
It is set in the registry and throughout my program I'll do file stuff
and create the path with:
GetUserDirectory( ) + _T("PrinterInfo.xml")
This one is my latest challenge. When I start up I check if that file
exists and if not I copy one in from my program directory.
It lands in c:\ProgramData\Reserve Analyst
Later I go to open it and it looks in:
c:\some long winded path\username\rooming or something\Reserve Analyst
How can I make vista use a consistent path? I really don't care where it
is as long as it stays the same.
Thanks, Dan.
David Ching
news:p2GGm.1460$Ka2....@newsfe08.iad...
Unfortunately, it is not possible for non-elevated apps to access the All
Users directory. Only elevated (admin) apps can. If possible, have your
installer (which is normally run as elevated anyway) put the PrinterInfo.xml
file into the All Users folder, or else use the per-user folders (which
non-elevated apps can access).
-- David
Scott McPhillips [MVP]
> is as long as it stays the same.
Call SHGetFolderPath to get the path to various directories. The
directories change names with different Windows versions and languages but
SHGetFolderPath is supposed to insulate you from all that.
--
Scott McPhillips [VC++ MVP]
Joseph M. Newcomer
On Fri, 30 Oct 2009 11:14:47 -0700, DanB <a...@some.net> wrote:
>
>Hi,
>This has been a real fight for me and I want to get it right before the
>next release.
>
> From the xp days I have a user settings folder, path:
>
>C:\Documents and Settings\All Users\Application Data\Reserve Analyst
>It is set in the registry and throughout my program I'll do file stuff
>and create the path with:
****
This is probably a serious error. First, it should not be stored in the Registry, but
computed on the fly. You should not try to access All Users, nor can you sensibly access
All Users\Application Data.
To get the path, you would have used code like
//----------------
// in stdafx.h
#define _WIN32_IE 0x500
#include <shlobj.h>
//-----------------
CString path;
LPTSTR p = path.GetBuffer(MAX_PATH);
HRESULT hr = ::SHGetFolderPath(CSIDL_COMMON_APPDATA, NULL, SHGFP_TYPE_CURRENT, p);
if(SUCCEEDED(hr))
{ /* succeeded */
path.ReleaseBuffer();
...your code here
} /* succeeded */
else
{ /* failed */
path.ReleaseBuffer();
...failure code here
} /* failed */
[Code generated by my SHGetFolderPath utility]
and therefore there would never, ever have been a need to store this explicit path in the
Registry. But here's the problem: there is no way you would be allowed to modify the
"Common AppData" from an arbitrary user application. The problem in XP was that most
users seemed to have admin privileges, and all developers had admin privileges, so nobody
noticed that security was being violated every time this was done.
Vista (and Windows 7) are much less forgiving of such bad design, and simply forbid
accessing the directory unless you have admin privileges. A program that requires admin
privileges will not be logo-certified, and in any case falls into that category known as
Fundamentally Bad Ideas. Programs that require admin privileges had better have an
extremely good reason for such power, and very few programs do.
****
>
>GetUserDirectory( ) + _T("PrinterInfo.xml")
>
>This one is my latest challenge. When I start up I check if that file
>exists and if not I copy one in from my program directory.
>
>It lands in c:\ProgramData\Reserve Analyst
>
>Later I go to open it and it looks in:
>c:\some long winded path\username\rooming or something\Reserve Analyst
****
Sorry, this is nonsensical. If you have information, you have to show it. There is no
possible way we can guess what you mean by "some long winded path" or "rooming or
something". There is a full path name there, and you are wasting our time and yours by
posting some silly interpretation of what you see. If you want a question answered, you
have to provide the critical information necessary to either answer it or explain why
there is a problem, and the above line does not meet this criterion.
I'm sure if you gave all the information we could explain what is happening. It probably
has to do with how Vista virtualizes certain kinds of restricted access to allow
badly-designed legacy code to continue to work, sort of.
****
>
>How can I make vista use a consistent path? I really don't care where it
>is as long as it stays the same.
****
Don't require a path that violates fundamental principles of data security. This means
you don't go mucking around in directories to which ordinary users to not have access. the
CSIDL_COMMON_APPDATA is one such directory.
Why is it that you want to modify the data that every user sees?
Note that the initial choice was a bad one on XP, but Vista actually out-of-the-box
enforces limitations that should have been present in the first version of NT that was
delivered. It is essential that we learn to live with these limitations. The failure to
adhere to these allows the introduction of fascinatingly deadly forms of malware, so the
adherence is now enforced, rather than optional.
joe
****
>
>
>Thanks, Dan.
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
DanB
> See below...
> On Fri, 30 Oct 2009 11:14:47 -0700, DanB <a...@some.net> wrote:
>
>> Hi,
>> This has been a real fight for me and I want to get it right before the
>> next release.
>>
>> From the xp days I have a user settings folder, path:
>>
>> C:\Documents and Settings\All Users\Application Data\Reserve Analyst
>> It is set in the registry and throughout my program I'll do file stuff
>> and create the path with:
> ****
> This is probably a serious error.
Yes, it is.
> First, it should not be stored in the Registry, but
> computed on the fly.
Gee, if I start a deployment in VS and look at the registry it gives me
these folders as if they are legitimate. Mind you deployment is a hat I
would rather not wear and I did the best I could with it back in 2002. I
didn't 'pick' this path, I was trying to follow the rules as I saw them
at the time.
It is why I go to the registry to get the path, because I let VS/msi
pick it for me.
(HKCU\Software\[Manufacturer])
> and therefore there would never, ever have been a need to store this explicit path in the
> Registry.
It came as baggage with VS deployment and at the time I had no idea
there would be new rules.
>> GetUserDirectory( ) + _T("PrinterInfo.xml")
>>
>> This one is my latest challenge. When I start up I check if that file
>> exists and if not I copy one in from my program directory.
>>
>> It lands in c:\ProgramData\Reserve Analyst
>>
>> Later I go to open it and it looks in:
>> c:\some long winded path\username\rooming or something\Reserve Analyst
> ****
> Sorry, this is nonsensical. If you have information, you have to show it. There is no
> possible way we can guess what you mean by "some long winded path" or "rooming or
> something". There is a full path name there, and you are wasting our time and yours by
> posting some silly interpretation of what you see.
Ok, then don't read my posts. For anyone that has run into the user data
path challenge on Vista, the above is perfectly clear. Why do you have
to berate folks? Did you loose someone you love and this is how you
vent? I'm sorry for your loss.
>> How can I make vista use a consistent path? I really don't care where it
>> is as long as it stays the same.
> ****
> Don't require a path that violates fundamental principles of data security. This means
> you don't go mucking around in directories to which ordinary users to not have access. the
> CSIDL_COMMON_APPDATA is one such directory.
>
> Why is it that you want to modify the data that every user sees?
Oh, believe me, I get this stuff. Painfully because of vista.
DanB
Thanks Scott, I'll give that a shot. I'll be doing some study before I
commit.
Best, Dan.
DanB
Well, I can't get it to work right. I had my client run a little program
so I could see the paths they were getting. This is Windows 7.
CSIDL_APPDATA: C:\Users\Namexxx\AppData\Roaming
CSIDL_LOCAL_APPDATA: C:\Users\Namexxx\AppData\Local
And I had them search the hard drive to find where the installer put my
program data.
C:\Users\Namexxx\AppData\Local\VirtualStore\ProgramData\Reserve Analyst
So, I still don't have a method to find this folder. I don't see any
other reasonable CSIDL on this list to try.
<http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx>
Thankfully this is an old client having fun helping me, and they are not
in a hurry to move to this box.
Thanks, Dan.
Joseph M. Newcomer
****
Actually, the rules are not new. Many of the rules were already in place; people just
ignored them. Just like people ignored the rules about GetWindowsSystemDirectory, and not
putting their own files in the Windows or Windows/System32 directories. SHGetFolderPath
existed in Windows 4.0.
It was a common error to reverse-engineer accidents of implementation and rely on them as
if they were some kind of truth. The documentation, however, was usually quite clear.
Note that no deployment logic would ever have indicated that the Common AppData folder was
a legitimate candidate for storing anything. The inference that it might have been was
not based on any known documented policy (which indicated that this was a Really Bad
Idea...I know, I was teaching this material since 1999).
****
>
>>> GetUserDirectory( ) + _T("PrinterInfo.xml")
>>>
>>> This one is my latest challenge. When I start up I check if that file
>>> exists and if not I copy one in from my program directory.
>>>
>>> It lands in c:\ProgramData\Reserve Analyst
>>>
>>> Later I go to open it and it looks in:
>>> c:\some long winded path\username\rooming or something\Reserve Analyst
>> ****
>> Sorry, this is nonsensical. If you have information, you have to show it. There is no
>> possible way we can guess what you mean by "some long winded path" or "rooming or
>> something". There is a full path name there, and you are wasting our time and yours by
>> posting some silly interpretation of what you see.
>
>Ok, then don't read my posts. For anyone that has run into the user data
>path challenge on Vista, the above is perfectly clear. Why do you have
>to berate folks? Did you loose someone you love and this is how you
>vent? I'm sorry for your loss.
****
No, I just get tired of people who ask for help and won't give the complete information
required to help them. Blather like "some long winded path" is completely meaningless,
and I'm sorry you aren't able to ask a coherent question, but I have no problems with
telling someone who does this that they are behaving badly. It's one thing to give
inadequate information ("My program doesn't work, what's wrong?") and another to HAVE the
information and FAIL to provide it, instead giving meaningless noise in place of a
coherent statement.
There are several different answers that are possible, depending on the EXACT content of
what you eliminated.
I don't countenance sloppiness in programming, or sloppiness in questions. I've been an
educator for most of my life, and I see the same irresponsible questioning techniques all
the time. I fail to see why it is so difficult to present the information that is
available. And I have given up on being "patient and understanding" when the questioner
actually makes an explicit effort to obfuscate the only critical information available.
****
>
>
>>> How can I make vista use a consistent path? I really don't care where it
>>> is as long as it stays the same.
>> ****
>> Don't require a path that violates fundamental principles of data security. This means
>> you don't go mucking around in directories to which ordinary users to not have access. the
>> CSIDL_COMMON_APPDATA is one such directory.
>>
>> Why is it that you want to modify the data that every user sees?
>
>Oh, believe me, I get this stuff. Painfully because of vista.
****
Vista merely enforces very strongly the policies that were put in place a decade ago or
more (many of these were semi-enforced in Windows 2000, but since everyone ran as
Administrator, nobody noticed they were doing Bad Things). Some policies were in place
when Windows NT 3.1 was released, but people kept programming as if they were using
Windows 16. So many of these polices have been documented since 1992 (that's almost 18
years). Vista just made them non-negotiable.
joe
****
Joseph M. Newcomer
On Sat, 31 Oct 2009 19:28:50 -0700, DanB <a...@some.net> wrote:
****
Actually, very few people have problems with the "user data path challenge" on Vista,
because it doesn't exist. It hasn't existed in years. For example, see
http://www.flounder.com/shgetfolderpath_explorer.htm
which I wrote in 2006, based on material I had been teaching for many years before that.
If anyone had a "user data path challenge", it was because they didn't read the
appropriate documents that explained that it doesn't exist. The problem was apparent in
NT4, became serious in Win2K, and all Vista did was enforce it, by making the default that
no user ran with admin privileges. Which is what should have been done in 1992.
So if your excuse is "it was always done wrong, we just got around to noticing it", then
that doesn't mean it is a challenge or a problem. Only that you missed the solution that
had been in place since the late 1990s.
joe
>
>
>>> How can I make vista use a consistent path? I really don't care where it
>>> is as long as it stays the same.
>> ****
>> Don't require a path that violates fundamental principles of data security. This means
>> you don't go mucking around in directories to which ordinary users to not have access. the
>> CSIDL_COMMON_APPDATA is one such directory.
>>
>> Why is it that you want to modify the data that every user sees?
>
>Oh, believe me, I get this stuff. Painfully because of vista.
DanB
> Actually, the rules are not new. Many of the rules were already in place; people just
> ignored them. Just like people ignored the rules about GetWindowsSystemDirectory, and not
> putting their own files in the Windows or Windows/System32 directories. SHGetFolderPath
> existed in Windows 4.0.
>
> It was a common error to reverse-engineer accidents of implementation and rely on them as
> if they were some kind of truth. The documentation, however, was usually quite clear.
>
> Note that no deployment logic would ever have indicated that the Common AppData folder was
> a legitimate candidate for storing anything. The inference that it might have been was
> not based on any known documented policy (which indicated that this was a Really Bad
> Idea...I know, I was teaching this material since 1999).
> ****
It was the best information I could find at the time. Sure, that
'everyone else' was doing it is no excuse. But Christ, that was in the
past and I can't change that.
And as I didn't make it clear, beating me about the head for a mistake I
now know was a mistake is not the sign of a 'good' teacher. You can not
make me change the past no matter how much we both might like that.
>> Ok, then don't read my posts. For anyone that has run into the user data
>> path challenge on Vista, the above is perfectly clear. Why do you have
>> to berate folks? Did you loose someone you love and this is how you
>> vent? I'm sorry for your loss.
> ****
> No, I just get tired of people who ask for help and won't give the complete information
> required to help them. <snip rest of rant>
> There are several different answers that are possible, depending on the EXACT content of
> what you eliminated.
The exact path of some guys computer a thousand miles away would be
meaningless. I didn't have that 'exact' path until today. The
'username/local/roaming/whatever' has plenty of meaning for those that
have been there.
> I don't countenance sloppiness in programming, or sloppiness in questions. I've been an
> educator for most of my life, and I see the same irresponsible questioning techniques all
> the time. I fail to see why it is so difficult to present the information that is
> available. And I have given up on being "patient and understanding" when the questioner
> actually makes an explicit effort to obfuscate the only critical information available.
If you can tell me what some arbitrary user path on someone's computer
has so much more meaning than what I posted, and it holds water, I'll
concur.
> Vista merely enforces very strongly the policies that were put in place a decade ago or
> more (many of these were semi-enforced in Windows 2000, but since everyone ran as
> Administrator, nobody noticed they were doing Bad Things). Some policies were in place
> when Windows NT 3.1 was released, but people kept programming as if they were using
> Windows 16. So many of these polices have been documented since 1992 (that's almost 18
> years). Vista just made them non-negotiable.
And I'm here to fix my error. So, I got it wrong the first time and now
I have to fix it. Isn't that what this group is all about?
Best, Dan.
DanB
Cheese, I can not change what I did in the past, I don't have the
appropriate time machine. I guess I have to say it more clearly. I got
it wrong. Now, you can continue to say I got it wrong, but I don't get
your point because it doesn't do anything except for your ego.
How about you help with my last post on the CSIDL in the stead? That, or
you would rather see me keep getting it wrong so you can keep beating me
about the head?
There is a saying about beating a dead horse....
Thanks, Dan.
David Ching
> Well, I can't get it to work right. I had my client run a little program
> so I could see the paths they were getting. This is Windows 7.
>
> CSIDL_APPDATA: C:\Users\Namexxx\AppData\Roaming
> CSIDL_LOCAL_APPDATA: C:\Users\Namexxx\AppData\Local
>
> And I had them search the hard drive to find where the installer put my
> program data.
>
> C:\Users\Namexxx\AppData\Local\VirtualStore\ProgramData\Reserve Analyst
>
> So, I still don't have a method to find this folder. I don't see any other
> reasonable CSIDL on this list to try.
>
As I said, anytime Windows diverts to VirtualStore is because your app
doesn't have sufficient access (I.e. it is not elevated to Admin) to access
the real folder but it wants your app to think it succeeded so that it would
continue to be (partially) functional. There is nothing you can do about
this. As I suggested, the workaround is to have your installer put the
desired file into the real folder because your app can't.
-- David
DanB
Hi David,
Thanks. So how do others do it? i.e. use the window installer to get
their product in the 'right' places? (And I'll cross the msi group)
If I stick with the way I'm doing it, (../allusers/appdata/...) it works
fine even if my data is split between two folders. I just can't
'programmaticly' write to that folder, i.e. copy a new file in, as I
don't have a way to find it other than engage the client with stuff they
should not have to do. But reading and writing the shipped files works fine.
When the client want to copy settings from an old computer I will have
to have them hunt it down as my 'open settings folder' is not useful.
I will also spend the morning researching this....
Also, the VS msi project set the app folder
[ProgramFilesFolder][Manufacturer]\[ProductName]
But it leaves the user appdata folder unassigned. Could it be as simple
as finding the correct 'virtual' path for the user folder assignment for
the MSI build?
When I think it is right I'll send the test CSIDL program off to someone
to see. For whatever reason both our vista machines install and work
fine from 'all users'...
Thanks, Dan.
David Ching
> Hi David,
> Thanks. So how do others do it? i.e. use the window installer to get their
> product in the 'right' places? (And I'll cross the msi group)
>
Your installer (.msi in your case, but it doesn't have to be, it could be an
ordinary .exe) can access allusers/appdata because it is run as elevated.
When you double click it, you get the prompt to click OK (and if you are
running from a non-admin account, you must supply admin's
username/password). That's what makes it elevated.
> If I stick with the way I'm doing it, (../allusers/appdata/...) it works
> fine even if my data is split between two folders. I just can't
> 'programmaticly' write to that folder, i.e. copy a new file in, as I don't
> have a way to find it other than engage the client with stuff they should
> not have to do. But reading and writing the shipped files works fine.
>
> When the client want to copy settings from an old computer I will have to
> have them hunt it down as my 'open settings folder' is not useful.
>
> I will also spend the morning researching this....
>
Would it work to write the new xml file into a per-user folder, not
allusers, but e.g. /users/david? Your app will work on this folder, always.
Your app would need to do this again when a different user ran your app, but
it might work. The .msi file will put the original xml file into the
allusers folder, and your app will write updated ones to the per-user
folder. And your app will read the one from per-user folder if available,
or if not, the one from allusers (since I believe reading from allusers is
OK).
Short of that, when your app needs to update the xml file in the allusers
folder, what you can do is have it launch another .exe that has a manfiest
set to requireAdministrator (that will like the .msi) prompt you to click OK
and if not running from an Admin account, prompt for admin's
username/password. Again, like the .msi, it will have free access to
allusers. But then an Admin must be available to supply username/password,
may not be an option if your app is deployed in enterprise.
> Also, the VS msi project set the app folder
>
> [ProgramFilesFolder][Manufacturer]\[ProductName]
>
> But it leaves the user appdata folder unassigned. Could it be as simple as
> finding the correct 'virtual' path for the user folder assignment for the
> MSI build?
>
That's the per user folder, not allusers, so I don't think it is relevant.
> When I think it is right I'll send the test CSIDL program off to someone
> to see. For whatever reason both our vista machines install and work fine
> from 'all users'...
>
Test it yourself by running your app from a Limited (non-Admin) account on
your own PC.
Regards,
David
DanB
Thanks. I may have made it sound like I need access to all users, but I
don't if I get this right. I don't want to have to run elevated and
trigger the UAC. This came to a head when I was patching a new feature
and wanted to copy in that new xml. It copied without elevation but to
the wrong place. The wrong place happened to be all users. And if I were
required to be elevated to write this folder, something was wrong in vista.
But even then I would think if I'm doing it by the rules the user app
data should be in a place 'I' can get to, do what I need, and without
elevation. And like I said, I don't care where this folder is. I'd like
it by the rules and were the installer puts it, and I can find it.
My objective is to use user-app-data by the rules, not to work around
them. I just want the 'right' place, a no special privileges place at
that. Per user is fine.
As far as working with the clients on pre release, they know that they
may have to do special stuff sometimes, and I'm not looking to fix that.
This is about our next full msi release. It is scheduled for the first
of the year but I would really like to avoid spending the next two
months just chasing this down. :)
Best, Dan.
David Ching
may be that xml file will be installed to the per-user folder of the user
that is installing (could be an IT Admin) and not the user that will be
running it; in that case, user running it won't have the xml file! That's
why I suggested installer put it in allusers and have per-user updates take
precedence.
-- David
"DanB" <a...@some.net> wrote in message
news:GnZHm.8758$Cc6....@newsfe07.iad...
Joseph M. Newcomer
Try to read the file from CSIDL_APPDATA
If that fails, read the file from CSID_COMMON_APPDATA
If that fails, either tell the user there is an unrecoverable problem, or have a set of
hardwired defaults that sort-of work.
When writing a file, always write to CSIDL_APPDATA. If you want the manufacturer and
product as directories, it is your responsibility to create them. So you would do
//----------------
// in stdafx.h
#define _WIN32_IE 0x500
#include <shlobj.h>
//-----------------
CString path;
LPTSTR p = path.GetBuffer(MAX_PATH);
HRESULT hr = ::SHGetFolderPath(CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, p);
if(SUCCEEDED(hr))
{ /* succeeded */
path.ReleaseBuffer();
...your code here
} /* succeeded */
else
{ /* failed */
path.ReleaseBuffer();
...failure code here
} /* failed */
which gives you the path
C:\Documents and Settings\username\Application Data
for the login username.
To that path you append \Manufacturer and try to create the directory. If it succeeds,
fails because the directory already exists, you can go to the next step, otherwise you
have to report an error and do some kind of recovery.
To the name
C:\Documents and Settings\username\Application Data\Manufacturer
you append \ProductName and try to create the directory. If it succeeds, or fails because
the directory already exists, you can go to the next step. Otherwise you have to report
an error and do some kind of recovery.
[Repeat as required, e.g, for version # of the product, etc.]
Finally, you have a full path to where you want to create the file; append the file name
and create the file. Note this is a per-user file. So during the install process, the
installer can create dialogs that provide custom parameterization to the site, which is
stored in the (read-only from anywhere else) common-appdata folder (the same techniques of
subdirectories apply here). So any app that starts up gets the default per-site settings
established at install time.
Now there is a question: what happens if the admin changes something but the local appdata
folders have the original data from the install? In this case, particularly for XML, what
you do is read per-site settings from the common-appdata folder, always, and save
user-modifiable settings to the user-appdata folder.
In the multi-user environment of Windows, you simply cannot have any individual users
modifying the common appdata in any way; this affects all users.
Note that once you write this subroutine, it is usable everywhere. While I've not done it
for XML, I've done it for other setting strategies, including (shudder) .INI files.
joe
****
Tom Serface
Rimage) to put save content. I think that's still sort of a standard
procedure.
Tom
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:0om1f5tlcbnbglqgs...@4ax.com...
David Ching
that is where the installer put it, and that isn't true if another user
(e.g. the administrator) installed the app from a different account. This
strategy doesn't handle the fact that it doesn't "fail" but it silently
redirects to VirtualStore where the document is not where the installer put
it.
-- David
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:0om1f5tlcbnbglqgs...@4ax.com...
David Ching
news:OiLhLoP...@TK2MSFTNGP06.phx.gbl...
> This strategy doesn't handle the fact that it doesn't "fail" but it
> silently redirects to VirtualStore where the document is not where the
> installer put it.
>
The trick to disabling VirtualStore is to include a manifest:
http://msdn.microsoft.com/en-us/library/bb756929.aspx
-- David
DanB
Hi Joe,
Thank you. I printed and read your post. I sincerely appreciate your time.
I did almost exactly what you wrote to get these paths from my client
with that test program.
hResult= SHGetFolderPath( NULL, CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT,
strUserPath.GetBuffer( MAX_PATH ) );
It is an SDI project with a CEditView so the client could copy and paste
the info to email. I'll be using this project to test the installer in
the future.
I will find the common folder useful as a repository for default data.
When my app installs it does create two folders on most Vista machines,
one in allUsers and one for the user themselves.(*side note below)
With our product the appData folder is very important. It contains the
information for headers, rtfs, report structures, footers, etc. What the
client's product will look like from our software.
For some clients my wife will make the product look like what they want
on her computer and then we ship the whole user data folder to them.
BTW, we use 'TeamViewer' now and are very happy with this product. We
had been through others, not the same.
And thanks David, the manifest looks very important so that the app has
the appropriate privileges to access the 'not' VirtualStore.
It looks like the last piece of this puzzle will be to get the installer
to create folders in the 'not' VirtualStore so that the CSIDL_APPDATA is
valid.
*side note:
On more than one machine I have seen my app read and write WinInfo.xml
in the common folder and all the rest in the user folder. This is with
Vista redirecting my goofy path. WinInfo is the first read and last
written. It is also the only file that is created at a first time use,
we don't ship it. So even without the manifest we seem to have
permission to write 'higher level' folders, so far...
And our software always runs properly on Vista, that is not my issue*.
It is having the path consistent as the user data is not a casual store.
So when the client does an 'Open Settings Folder' they get to the folder
that has their data.
*I finished up with the windows7 client yesterday, just settled for the
VirtualStore place and I copied their settings into it. Works fine. But
it is another computer we are not properly installed on. But I can
TeamViewer in and change the registry entry and make life look good.
Again, thank you very much.
Best, Dan.
Joseph M. Newcomer
****
This is the per-site customization I was talking about. In such a case, the custom
features are placed in the common appdata folder, and read from there. Per-user settings
are read from the user appdata folder. However, there is never anything written to the
common appdata folder. Per user customizations are written to the user appdata folder.
This requires some careful design to distinguish what are "site-specific" features and
what are "user-specific" features, and furthermore, whether some "user-specific" options
can override "site-specific" options. This is a common set of problems which many
programs have. Consider that there is site-specific option A which has value VA. This is
established at install time. An individual user may be able to override this with a value
UA. In that case, the per-user appdata will store option A. The aglorithm is to read
value VA, then reading the per-user value UA which overrides it. But if the user is not
permitted to change the value of option A, then it is never stored in the user appdata
folder. So the options are divided into
Site options that cannot be overridden
Site options that can be overridden by per-user options
User options that never appear in the site options but default if not specified
User options that never appear in the site options but must be specified
and have no defaults
Therefore, it is not possible to think of *a* configuration file, but always two
configuration files. The "saved" user configuration can only save to the user appdata,
and will not include any options that cannot be overridden. The final configuration
involves the merge of these two configuration files, reading the site-specific then the
user-specific options. The save has to know what options to save in the user-specific
appdata. In addition, it is useful to provide a means for someone with admin privileges
to save site options. This can be done either by a separate program, or by running the
application as admin and having a "Save Site Options..." menu item, which saves *only* the
site-specific options.
I usually store options in the Registry and do this sort of thing with HKLM and HKCU, and
I recently helped someone implement this strategy for a database system with two database
configuration files that contain specifications such as the headers and footers, billing
rates, billing cycles, etc. Customization of the site is done by the vendor (with whom I
am consulting) but per-user settings are also provided.
****
>
>And our software always runs properly on Vista, that is not my issue*.
>It is having the path consistent as the user data is not a casual store.
>So when the client does an 'Open Settings Folder' they get to the folder
>that has their data.
****
The virtual stores are stated as being a temporary hack which may not be supported in
future releases, but which are used to maintain compatibility with earlier code.
Therefore, it is not safe to assume that this mechanism will continue to work.
joe
****
>
>*I finished up with the windows7 client yesterday, just settled for the
>VirtualStore place and I copied their settings into it. Works fine. But
>it is another computer we are not properly installed on. But I can
>TeamViewer in and change the registry entry and make life look good.
>
>Again, thank you very much.
>Best, Dan.
DanB
>> And our software always runs properly on Vista, that is not my issue*.
>> It is having the path consistent as the user data is not a casual store.
>> So when the client does an 'Open Settings Folder' they get to the folder
>> that has their data.
> ****
> The virtual stores are stated as being a temporary hack which may not be supported in
> future releases, but which are used to maintain compatibility with earlier code.
> Therefore, it is not safe to assume that this mechanism will continue to work.
Yes, thank you. I understand I don't want to install in the virtual
store, that doesn't work for me. I'm researching what is the appropriate
way to set up the msi so the folders get created in the proper place. I
think that is my last hurdle. And when I get this right we will burn a
fresh master right away for new clients. I was hoping to get that last 7
client a new CD but I can see this may take some time.
And if possible, when we send out the 'new release' in a few months, I
will be able to move my old vista/7 client's app data to this
appropriate place. I won't try to fix this for old XP clients, there are
too many of them out there and our old installed configuration on XP
works at 100%. I doubt there will be a service patch that will 'break'
XP. If there is, my work is cut out for me and a lot of other folks! :)
Best, Dan.
Stephen Myers
Along these same lines, I wonder if you can help me with a related problem.
We have a number of per site files which individual users need to be
able to update. Where do these files belong?
There is on the order of 10 MBytes of data that I'm concerned about. We
could easily have 3 or 4 active versions, so say 50MBytes total.
(This seems like more than I want in the registry, but I'm open to
suggestion.)
Steve
Joseph M. Newcomer
****
This leads to some interesting problems about the integrity of the values. For example,
if I have a global (multi-user-accessible) file at time T0, it has an option A which has a
value VA, and at T0 I can call this VA0. Some time later, at T1, user U1 updates the file
so it has value VA1. Now the problem is, what about all the users who read the
configuration file at time T0? They need to know that the file has been modified, and
that they must reload. (This can be done by ReadDirectoryChangesW, for example, but it
has to be done explicitly).
In addition, you have to deal with the fact that at time T1, user 1 (U1) is trying to do
an update, but so is user 2 (U2). So suppose U1 is writing back VA0 and VB1, while U2 is
writing back a change to option A and is writing VA1 and VB0. One of the two changes is
going to get lost. How do you handle such a situation?
Note that this is a problem intrinsic to multiuser access to any common data repository,
whether it be an XML file or a Registry value. It also arises in database situations and
transactional methods do not allow consistency unless the read AND the write take place as
part of a single transaction. Therefore, you have to separate out the notions of reading
and updating; an "update" would consist of opening the file exclusive, reading the
*current* settings in, updating them, and writing them back.
As far as file location, the nature of COMMON_APPDATA is that it is by default privileged.
It might be possible to have the installer create a subdirectory which is open to all
users, but this gets into some issues about logo certification which I am not fully
conversant with. But you can't just rewrite the file from internal state. The internal
state can only be considered valid if it is read from a locked file; otherwise it is
potentially stale data.
****
>
>There is on the order of 10 MBytes of data that I'm concerned about. We
> could easily have 3 or 4 active versions, so say 50MBytes total.
>(This seems like more than I want in the registry, but I'm open to
>suggestion.)
****
Mostly, see above. The alternative is to store it as an actual database file with
transactions to control the access.
joe
****
>
>Steve
David Wilkinson
> And thanks David, the manifest looks very important so that the app has
> the appropriate privileges to access the 'not' VirtualStore.
Actually, it is the opposite. In order to have permission to write to the
"forbidden places", you will need an "admin" manifest that will cause a UAC
elevation prompt, which you almost certainly don't want (except in the
installer). In your app, you should put a "non-admin" manifest that will cause
writes to the forbidden places to fail. That way, you will find out if you try
to do something in your app that you are not supposed to do. The VirtualStore is
only intended for legacy applications that are not being updated. New work
should avoid it.
--
David Wilkinson
Visual C++ MVP
Stephen Myers
I apologize for not fully stating my problem. (You'd think I would know
by now...)
My situation is simplified in that there will never be more than one
user logged on at any given time. I'm acquiring data in pseudo real
time so multiple simultaneous users doesn't make sense.
What will happen is that user A will have updates that user B will need
(after A has logged off.)
>
> Note that this is a problem intrinsic to multiuser access to any common data repository,
> whether it be an XML file or a Registry value. It also arises in database situations and
> transactional methods do not allow consistency unless the read AND the write take place as
> part of a single transaction. Therefore, you have to separate out the notions of reading
> and updating; an "update" would consist of opening the file exclusive, reading the
> *current* settings in, updating them, and writing them back.
>
> As far as file location, the nature of COMMON_APPDATA is that it is by default privileged.
> It might be possible to have the installer create a subdirectory which is open to all
> users, but this gets into some issues about logo certification which I am not fully
> conversant with. But you can't just rewrite the file from internal state. The internal
> state can only be considered valid if it is read from a locked file; otherwise it is
> potentially stale data.
> ****
>> There is on the order of 10 MBytes of data that I'm concerned about. We
>> could easily have 3 or 4 active versions, so say 50MBytes total.
>> (This seems like more than I want in the registry, but I'm open to
>> suggestion.)
> ****
> Mostly, see above. The alternative is to store it as an actual database file with
> transactions to control the access.
We'll consider this. Unfortunately, there is a lot of inertia involved.
Thanks for you comments.
Steve
DanB
Hi David,
I'll make myself clear. I know I don't want to be in the virtual store
it makes me somewhat broken. I don't want special privileges, I only
want to read and write 'my' appData folder. I want to find this folder
where CSIDL_APPDATA will point. I want the installer to create my folder
where CSIDL_APPDATA will point, not the virtual store as it is doing now.
<http://msdn.microsoft.com/en-us/library/bb756929.aspx>
I would write the manifest as:
Application launch behavior for a standard user account
asInvoker
I have no interest in triggering 'allow or deny' from the UAC and I do
nothing, nor ever plan to do something, on the client's box that should
ever require it.
And I would use the manifest as I don't know if it will be a future
requirement for apps that use the 'right' folder. It looks like the safe
route. For now it seems that the manifest is not required for normal
access to the CSIDL_APPDATA/MyData folder. But now that the lights are
coming on, and I've been warned things could change, I have no interest
in gambling.
Now, if CSIDL_APPDATA/MyData is a "forbidden place" there is something
very wrong with my understanding, or Vista/Windows7.
Best, Dan.
David Wilkinson
> I'll make myself clear. I know I don't want to be in the virtual store
> it makes me somewhat broken. I don't want special privileges, I only
> want to read and write 'my' appData folder. I want to find this folder
> where CSIDL_APPDATA will point. I want the installer to create my folder
> where CSIDL_APPDATA will point, not the virtual store as it is doing now.
>
> <http://msdn.microsoft.com/en-us/library/bb756929.aspx>
>
> I would write the manifest as:
> Application launch behavior for a standard user account
> asInvoker
>
> I have no interest in triggering 'allow or deny' from the UAC and I do
> nothing, nor ever plan to do something, on the client's box that should
> ever require it.
>
> And I would use the manifest as I don't know if it will be a future
> requirement for apps that use the 'right' folder. It looks like the safe
> route. For now it seems that the manifest is not required for normal
> access to the CSIDL_APPDATA/MyData folder. But now that the lights are
> coming on, and I've been warned things could change, I have no interest
> in gambling.
>
> Now, if CSIDL_APPDATA/MyData is a "forbidden place" there is something
> very wrong with my understanding, or Vista/Windows7.
CSIDL_APPDATA is not the forbidden place, and will not be virtualized.
CSIDL_COMMON_APPDATA is the forbidden place.
CSIDL_APPDATA is different for each user. Any user can write to their own
CSIDL_APPDATA. Personally, I would not write to CSIDL_APPDATA in the installer,
because you do not know that the person who is installing the software is the
same person that will be using it. I would have the installer write to
CSIDL_COMMON_APPDATA, and if the user of the program has to modify their own
copy, then have them write it to CSIDL_APPDATA.
DanB
Hi David,
This would be an instance where 'my client' is more than one login, it
could happen. When you say, 'have them write it...', I would say I would
see if the folder exists and if it doesn't, I would create it and copy
in from the common data. I would not make my client do this if I could
avoid it.
Here is the rub. If a second user were to log on they would want to see
the software set up like the first user had set it up, not our defaults.
That is the nature of our product. We have site/user data that Joe was
talking about. The only things that would be user specific are the MRU
and win positions.
But it would be very, very rare to find more than one user on a machine
using our product. So even when I do address this it is back burner to
getting that one user right first.
But out of the gate, I will take your advice and create the APPDATA
folder on first use rather than letting the installer do it. And this
may be the answer to my last challenge! Thanks.
There is another thing I'm starting to wonder about, I took it for
granted as I've never had a problem. Our clients store there data,
(different than settings), typically in a root folder like:
C:\Studies
(A few use a server, so F:\Studies, And one where I actually picked up
the look of the product from the server. But once they settled in they
didn't need the 'server switch'. Turtle's all the way down for me!)
They share this folder on the network so others in the office have
access to the Studies. I had not heard of a 'logo certification' until
Joe mentioned it. Is this in my future!?
My primary mission is to make all this as seamless as possible for our
clients. They should not 'have to know' what they don't need to know.
Otherwise, I'm not doing my job properly. I'm getting itchy and why I'm
asking these questions.
I'm guessing that folks here don't mind this discussion as it has a
direct impact on their MFC products.
Best, Dan.
Joseph M. Newcomer
****
What you have here is a shared-data problem. There are several ways to handle this:
1. Make the data accessible via a service, using a named pipe or TCP/IP connections. The
service "owns" the data and the clients just use/update it.
2. Create a single, common directory with the correct permissions and put the file there.
Then you have to make sure the issues of what happens if two users just happen to be
logged in simultaneously arises. Note that under multiuser scenarios like terminal
services this is a common situation. If nothing else, you have to open the file exclusive
when the program starts. The file is never closed until the program exits. This prevents
*anyone else* from modifying it hwile it is active. A bit extreme for some situations, it
might fit yours.
Now note: it *might* be possible to create a shared folder under the CSIDL_COMMON_APPDATA;
I haven't looked to see how protections are set to inherit in those directories. So while
CSIDL_COMMON_APPDATA/Manufacturer may be set read-only by default, you might be able to
create a CSKD_COMMON_APPDATA/Manufacturer/SharedData folder which *is* accessible to a
selected number of users (at this point, you have to look at what your installer can do
with directory protections, whether or not the solid protection is mandatory so you can't
even create a shared folder, who you wish to allow to share it, etc., etc.) Alternatively,
you might create a simple top-level shared folder as you describe below (d:\Studies). I
don't do a lot with sharing protection, so I can't suggest the best strategy to use here.
3. Put it in a database and use a database server (a generalization of the first option)
It should not come as a surprise to a user to log in, run the program, and find that
*nothing* is as they left it yesterday. Therefore, you are running against the "principle
of least surprise" that governs most designs. The users need to understand that this is
what is going to happen.
Alternatively, you can split the data into three components: site-default, user-specific
and shared. So the user-specific settings remain (simple things like what printer to use,
for example), and shared settings involve things like the total picture of the data after
it has been updated. Then you look at the most appropriate mechanism to implement this
strategy. But lumping everything into a single file is probably not a good strategy,
because you will find that eventually it breaks down into the three categories. More
commonly two categories, but for you the third, per-site defaults, is important.
Databases do this implicitly. Generally, they simplify things because there are no
per-site settings, so there are only per-user (stored in the Registry, a config file in
CSIDL_APPDATA, or a config file someplace else user-specific) settings and global (the
database information) settings; that was what made the exercise I did a while ago to get a
database with per-site settings a bit unusual; that doesn't usually happen.
Once you realize there are three kinds of data, then you can approach the problem of how
to represent the data more readily, because you have a model you can use to break the
problem down.
****
>
>But it would be very, very rare to find more than one user on a machine
>using our product. So even when I do address this it is back burner to
>getting that one user right first.
>
>But out of the gate, I will take your advice and create the APPDATA
>folder on first use rather than letting the installer do it. And this
>may be the answer to my last challenge! Thanks.
>
>There is another thing I'm starting to wonder about, I took it for
>granted as I've never had a problem. Our clients store there data,
>(different than settings), typically in a root folder like:
>C:\Studies
>(A few use a server, so F:\Studies, And one where I actually picked up
>the look of the product from the server. But once they settled in they
>didn't need the 'server switch'. Turtle's all the way down for me!)
>
>They share this folder on the network so others in the office have
>access to the Studies. I had not heard of a 'logo certification' until
>Joe mentioned it. Is this in my future!?
****
If you want your product to have the Microsoft logo "Designed for Windows Vista" or
"Designed for Windows 7", then you need to go through logo certification. And while some
people need this (they sell their product in boxes), custom developers can usually ignore
it. BUT: the requirements for logo certification are good-practice guidelines, and are
designed to keep you from creating software which won't run, or which, in order to run,
has to open up security which creates potential hazards (for example, if your product is
accessible via the Web, could a malicious organization send your program an "ill formed"
packet which can grab control from the machine?).
I spent six weeks developing a solution for a company that had been selling XP-based
solutions that no longer worked in Vista. They required logo certification (if you are
logo-certified, you can also make your product available through microsoft marketing Web
sites on something.microsoft.com, I forget what the something is). I spent three weeks
becoming an expert in Vista integrity levels, and three weeks rewriting their code to not
require admin privileges while still doing what needed to be done. And three weeks later
I had forgotten most of what I knew about integrity levels...
So logo certification is purely an option, but because it represents good-practice
guidelines, lets you avoid the kind of pitfall you just fell into, and can give you
marketing opportunities, it is worth reading the requirements and insofar as possible
adhering to them. I review them every couple years because I build my software as best I
can to follow them; it saves my clients from having problems if their product is installed
in a site that is serious about security (I started doing this with Win2K, where the
client was selling to Fortune n00 companies, and we had to fit within their security
guidelines, which were often as restrictive as Vista is. The difference was in Win2K, you
had to modify the out-of-the-box (OOB) settings for every install to enhance security;
with VIsta, the security is implicit in the OOB installation).
****
>
>My primary mission is to make all this as seamless as possible for our
>clients. They should not 'have to know' what they don't need to know.
>Otherwise, I'm not doing my job properly. I'm getting itchy and why I'm
>asking these questions.
****
As part of the install, you would ask about the shared directory for the common data
files, and have a default (e.g., c:\Studies) and an option to create one. I'm less
certain of how you might want to handle access. The write access should be limited to the
users who are actually doing something, otherwise, any program from any user at any time
[read: malware] can overwrite the data. If the data is "sensitive" in any way [e.g.,
HIPPA or equivalent] you would need to limit the read access. Law and corporate policies
begin to be more and more important these days; I did a system a while ago where we had to
deal with serious security issues based on the client security policies (it was a shell
extension that had to be very limited in what it was allowed to do, and the way it created
new entitites was constrained by the security policies). So while logo certification may
or may not be part of your future, security is very real and very now.
The major difference between XP and Vista/Win7 is that Vista and Win7 do OOB enforcement
of what used to be optional policies.
joe
****
>
>I'm guessing that folks here don't mind this discussion as it has a
>direct impact on their MFC products.
>
>Best, Dan.
DanB
Hi Joe,
Thank you.
I have been muling this over for quite some time. I know I need to
extend my 'server' concept, (that certain configurations need to be
shared). This has not been a major issue as these configurations remain
fairly static. Like the instance where my wife sets them up for a client
and then they are almost never changed. When I did the 'sever' thing I
had the files privileged locked.
I really have two issues on the table now and I do have a grip on the
second, sharing a configuration. That, as long as I can obtain proper
permissions across the network, and I have yet to have a problem with
that. As far as the per machine login, this should not be an issue if I
evolve the product configuration. File, folder, locking is a simple
enough implementation, I've done it before.
As far as the 'data' goes, what is in c:\Studies, it is not often that
two individuals will work on the same study at the same time. At that,
they know that the 'project info' is last close wins. But I have
considered locking to avoid misunderstandings. A project consists of two
files, and some dozen report files that never get modified by two
people. An xml with the project parameters, 'project info', and an mdb
with the components of the study. Most work is done on the components
and this works out nicely as two people can share the work and locking
is done at the record level.
As far as my original problem, getting out of the virtual store, I'm
doing two things. building a test msi and installing as guest on my
laptop. And the laptop is downloading VS 2010 beta right now so I can
see what the latest deployment tools look like.
The 'share configuration' thing is mostly a pita when a client gets a
new computer and wants to copy from an older machine. That's what
started this. My 'open settings folder' kicks off a windows explorer in
the APP_DATA/MyData folder. And because I've been installing in the
virtual store on Vista, I have no way to find this folder
programmatically. I have had to search the hard drive to find it.
Once I find it, I put a short cut to the folder on the desktop, but this
is just a hack I'm trying to fix.
Yes, I've researched the logo and came to the same conclusion. I should
comply with the guidelines, but I don't need to fork out the money for
it. And that it has nothing to do with application access across the
network.
> I spent six weeks developing a solution for a company that had been selling XP-based
> solutions that no longer worked in Vista. They required logo certification (if you are
> logo-certified, you can also make your product available through microsoft marketing Web
> sites on something.microsoft.com, I forget what the something is). I spent three weeks
> becoming an expert in Vista integrity levels, and three weeks rewriting their code to not
> require admin privileges while still doing what needed to be done. And three weeks later
> I had forgotten most of what I knew about integrity levels...
Well, thankfully I have never written in code that required more than
user privileges. Like I said, we install and run fine on Vista/7. The
UAC is never triggered. The crumb thing is something else, settings are
tagged 'Not Installed' and this seems to keep the folder in place on an
uninstall. I have to do this or the clients settings would get wiped out
on a major upgrade. I'm sure I can find a way to ask to delete this
folder on an uninstall and will look into doing it. But I have to ask
rather than assume someone's work should get wiped.
> So logo certification is purely an option, but because it represents good-practice
> guidelines, lets you avoid the kind of pitfall you just fell into, and can give you
> marketing opportunities, it is worth reading the requirements and insofar as possible
> adhering to them. I review them every couple years because I build my software as best I
> can to follow them; it saves my clients from having problems if their product is installed
> in a site that is serious about security (I started doing this with Win2K, where the
> client was selling to Fortune n00 companies, and we had to fit within their security
> guidelines, which were often as restrictive as Vista is. The difference was in Win2K, you
> had to modify the out-of-the-box (OOB) settings for every install to enhance security;
> with VIsta, the security is implicit in the OOB installation).
> ****
>> My primary mission is to make all this as seamless as possible for our
>> clients. They should not 'have to know' what they don't need to know.
>> Otherwise, I'm not doing my job properly. I'm getting itchy and why I'm
>> asking these questions.
> ****
> As part of the install, you would ask about the shared directory for the common data
> files, and have a default (e.g., c:\Studies) and an option to create one.
With a "new install, create new project", we detect that the 'data'
folder has not been set for the user. We ask and offer a CFolderDialog
to set, (and if needed, create), this folder parameter so the next time
they go for data we start them in this folder.
> I'm less
> certain of how you might want to handle access. The write access should be limited to the
> users who are actually doing something, otherwise, any program from any user at any time
> [read: malware] can overwrite the data. If the data is "sensitive" in any way [e.g.,
> HIPPA or equivalent] you would need to limit the read access. Law and corporate policies
> begin to be more and more important these days; I did a system a while ago where we had to
> deal with serious security issues based on the client security policies (it was a shell
> extension that had to be very limited in what it was allowed to do, and the way it created
> new entitites was constrained by the security policies). So while logo certification may
> or may not be part of your future, security is very real and very now.
Yes, here we have not done anything. If the client does not have a
decent firewall, they are vulnerable. I will have to address what is
within my scope of responsibility where security is concerned. Usually
anyone with a network have an IT that deal with security as our data is
small fry compared to the rest of the data on their network. Studies are
distributed publicly so there really is nothing secret in our data.
Networked clients usually backup daily.
> The major difference between XP and Vista/Win7 is that Vista and Win7 do OOB enforcement
> of what used to be optional policies.
I'll keep this group up to date on how the manifest thing and 'new'
install goes.
Thanks, Dan.
Joseph M. Newcomer
****
The problem is that you have to keep a "reference count" of how many users have the
program installed, which is hard because you really don't know, for a network server, how
many machines might have access to that network folder. So sometimes the safest thing is
to leave the directory alone.
****
>
>
>> So logo certification is purely an option, but because it represents good-practice
>> guidelines, lets you avoid the kind of pitfall you just fell into, and can give you
>> marketing opportunities, it is worth reading the requirements and insofar as possible
>> adhering to them. I review them every couple years because I build my software as best I
>> can to follow them; it saves my clients from having problems if their product is installed
>> in a site that is serious about security (I started doing this with Win2K, where the
>> client was selling to Fortune n00 companies, and we had to fit within their security
>> guidelines, which were often as restrictive as Vista is. The difference was in Win2K, you
>> had to modify the out-of-the-box (OOB) settings for every install to enhance security;
>> with VIsta, the security is implicit in the OOB installation).
>> ****
>>> My primary mission is to make all this as seamless as possible for our
>>> clients. They should not 'have to know' what they don't need to know.
>>> Otherwise, I'm not doing my job properly. I'm getting itchy and why I'm
>>> asking these questions.
>> ****
>> As part of the install, you would ask about the shared directory for the common data
>> files, and have a default (e.g., c:\Studies) and an option to create one.
>
>With a "new install, create new project", we detect that the 'data'
>folder has not been set for the user. We ask and offer a CFolderDialog
>to set, (and if needed, create), this folder parameter so the next time
>they go for data we start them in this folder.
****
The person who does the install on their machine can only create a folder for their own
login account; you can't really go off and create folders for other users. A sysadmin
doing an install for a set of users can create a shared directory, but as each startup
occurs, the individual user has to set any custom settings.
****
>
>> I'm less
>> certain of how you might want to handle access. The write access should be limited to the
>> users who are actually doing something, otherwise, any program from any user at any time
>> [read: malware] can overwrite the data. If the data is "sensitive" in any way [e.g.,
>> HIPPA or equivalent] you would need to limit the read access. Law and corporate policies
>> begin to be more and more important these days; I did a system a while ago where we had to
>> deal with serious security issues based on the client security policies (it was a shell
>> extension that had to be very limited in what it was allowed to do, and the way it created
>> new entitites was constrained by the security policies). So while logo certification may
>> or may not be part of your future, security is very real and very now.
>
>Yes, here we have not done anything. If the client does not have a
>decent firewall, they are vulnerable. I will have to address what is
>within my scope of responsibility where security is concerned. Usually
>anyone with a network have an IT that deal with security as our data is
>small fry compared to the rest of the data on their network. Studies are
>distributed publicly so there really is nothing secret in our data.
>Networked clients usually backup daily.
****
It isn't always a firewall issue. If you have seven users, but only three are supposed to
access the file, what are you doing about the other four? There are legal implications if
you do something that can cause an information leak of what might be "personal data". Or
proprietary scientific data.
****
>
>> The major difference between XP and Vista/Win7 is that Vista and Win7 do OOB enforcement
>> of what used to be optional policies.
>
>I'll keep this group up to date on how the manifest thing and 'new'
>install goes.
>
>Thanks, Dan.
DanB
>> Well, thankfully I have never written in code that required more than
>> user privileges. Like I said, we install and run fine on Vista/7. The
>> UAC is never triggered. The crumb thing is something else, settings are
>> tagged 'Not Installed' and this seems to keep the folder in place on an
>> uninstall. I have to do this or the clients settings would get wiped out
>> on a major upgrade. I'm sure I can find a way to ask to delete this
>> folder on an uninstall and will look into doing it. But I have to ask
>> rather than assume someone's work should get wiped.
> ****
> The problem is that you have to keep a "reference count" of how many users have the
> program installed, which is hard because you really don't know, for a network server, how
> many machines might have access to that network folder. So sometimes the safest thing is
> to leave the directory alone.
> ****
Hi Joe,
This would be in a single machine, single install case. If they created
a shared repository, 'multiple users', as would be the case with
multiple installs, it would most certainly be beyond the scope of our
software to delete this. Any folder created after the install is beyond
our scope of control. And after all, it would not be created at install
time. Only if the user settings are in the APP_DATA, and I would ask.
Two 'separate' users on one computer are about non existent with our
stuff. And by the time they had done any real work on their settings,
they should have it backed up.
Where this would be important for me is when a demo is ordered. The user
installs to take our stuff around the block and then uninstalls it. We
should clean up in that case. For now a folder gets left behind with a
few hundred k of stuff in APP_DATA. In the demo's case, I should
silently delete the folder.
>>> As part of the install, you would ask about the shared directory for the common data
>>> files, and have a default (e.g., c:\Studies) and an option to create one.
>> With a "new install, create new project", we detect that the 'data'
>> folder has not been set for the user. We ask and offer a CFolderDialog
>> to set, (and if needed, create), this folder parameter so the next time
>> they go for data we start them in this folder.
> ****
> The person who does the install on their machine can only create a folder for their own
> login account; you can't really go off and create folders for other users. A sysadmin
> doing an install for a set of users can create a shared directory, but as each startup
> occurs, the individual user has to set any custom settings.
> ****
A folder created for multiple users is beyond our scope. If a user tries
to create the folder and it fails, this is between that user and the OS.
I would not venture to arbitrate this disagreement. CFolderDialog starts
in the user folder where he can create the folder.
We have two kinds of clients. A single user working on their own machine
and data on their own machine, and multiple users sharing the data area.
In both cases data is create after the install. And just like any Office
product, where the data goes is not our business. How they share the
data is their business. If a new user comes on line and wants to select
the shared folder, the IT guy should see that they are able.
>> Yes, here we have not done anything. If the client does not have a
>> decent firewall, they are vulnerable. I will have to address what is
>> within my scope of responsibility where security is concerned. Usually
>> anyone with a network have an IT that deal with security as our data is
>> small fry compared to the rest of the data on their network. Studies are
>> distributed publicly so there really is nothing secret in our data.
>> Networked clients usually backup daily.
> ****
> It isn't always a firewall issue. If you have seven users, but only three are supposed to
> access the file, what are you doing about the other four? There are legal implications if
> you do something that can cause an information leak of what might be "personal data". Or
> proprietary scientific data.
> ****
If a client decides to put their data in a shared pool I don't see how I
have anything to do with who has permission. Even if I stop them as if
some kind of last resort, they would still have full access with notepad
and Access, so, my policing really means nothing. In every case the
client has an IT guy that takes care of this stuff, as it should be.
Best, Dan.
Joseph M. Newcomer
****
Several of my clients have a "demo version" of the software. It has a slightly different
installer, and parts of the code are not compiled in, e.g., #ifndef DEMO_VERSION allows
the code to exist in the non-demo version. In such a case, the install would create a
...\Demo folder to hold the data (where ... is some appropriate path selection), and would
always delete it upon uninstall.
Most of them get real nervous about releasing a "full" version with a timeout date,
because that is far too easily defeated. I hung out on cracker sites for about a year
using an anonymized path, and what I discovered about cracking protection schemes is
rather scary if you have software of any value. Fundamentally, software-only schemes are
crackable, and experts can crack them in 8-24 hours. Hardware schemes using external keys
seem the most secure, and seem to not be crackable.
****
>>>> As part of the install, you would ask about the shared directory for the common data
>>>> files, and have a default (e.g., c:\Studies) and an option to create one.
>
>>> With a "new install, create new project", we detect that the 'data'
>>> folder has not been set for the user. We ask and offer a CFolderDialog
>>> to set, (and if needed, create), this folder parameter so the next time
>>> they go for data we start them in this folder.
>
>> ****
>> The person who does the install on their machine can only create a folder for their own
>> login account; you can't really go off and create folders for other users. A sysadmin
>> doing an install for a set of users can create a shared directory, but as each startup
>> occurs, the individual user has to set any custom settings.
>> ****
>
>A folder created for multiple users is beyond our scope. If a user tries
>to create the folder and it fails, this is between that user and the OS.
>I would not venture to arbitrate this disagreement. CFolderDialog starts
>in the user folder where he can create the folder.
****
Sounds reasonable.
****
>
>We have two kinds of clients. A single user working on their own machine
>and data on their own machine, and multiple users sharing the data area.
>In both cases data is create after the install. And just like any Office
>product, where the data goes is not our business. How they share the
>data is their business. If a new user comes on line and wants to select
>the shared folder, the IT guy should see that they are able.
****
Key here is to distinguish between "data" which is shared, and "settings" which might be
per-user and/or per-site.
****
>
>
>>> Yes, here we have not done anything. If the client does not have a
>>> decent firewall, they are vulnerable. I will have to address what is
>>> within my scope of responsibility where security is concerned. Usually
>>> anyone with a network have an IT that deal with security as our data is
>>> small fry compared to the rest of the data on their network. Studies are
>>> distributed publicly so there really is nothing secret in our data.
>>> Networked clients usually backup daily.
>> ****
>> It isn't always a firewall issue. If you have seven users, but only three are supposed to
>> access the file, what are you doing about the other four? There are legal implications if
>> you do something that can cause an information leak of what might be "personal data". Or
>> proprietary scientific data.
>> ****
>
>If a client decides to put their data in a shared pool I don't see how I
>have anything to do with who has permission. Even if I stop them as if
>some kind of last resort, they would still have full access with notepad
>and Access, so, my policing really means nothing. In every case the
>client has an IT guy that takes care of this stuff, as it should be.
****
I agree. If you allow them to change the target site for the data, then the sharing
policies are entirely up to them. My concern was if the installer program had to create a
shared folder as part of the install.
That is, if you assume on the install a single-user-single-data-repository scenario, then
all you do is put the data in My Documents, and the settings in the CSIDL_APPDATA. if
they want to reconfigure it afterwards, they can move the data repository somewhere else.
Each user then has to change their settings to track it, or the sysadmin creates the
shared folder and sets the default path in the global settings (which only the sysadmin
can change) to reference that. So you treat the setting as one of the following
global, with no local override
global, with local override
local, with no global default (but perhaps a hardwired default)
It doesn't matter which you choose; but just keep in mind that only someone with admin
privileges can change the global settings, which means ordinary users cannot. Then you
don't need to worry about CSIDL_COMMON_APPDATA modification by ordinary users.
As far as I know, virtualization kicks in only if you try to write it. Then things go
really weird because of how the search is done on an open-for-read.
joe
****
>
>
>Best, Dan.
DanB
>>
> ****
> Several of my clients have a "demo version" of the software. It has a slightly different
> installer, and parts of the code are not compiled in, e.g., #ifndef DEMO_VERSION allows
> the code to exist in the non-demo version. In such a case, the install would create a
> ...\Demo folder to hold the data (where ... is some appropriate path selection), and would
> always delete it upon uninstall.
>
> Most of them get real nervous about releasing a "full" version with a timeout date,
> because that is far too easily defeated. I hung out on cracker sites for about a year
> using an anonymized path, and what I discovered about cracking protection schemes is
> rather scary if you have software of any value. Fundamentally, software-only schemes are
> crackable, and experts can crack them in 8-24 hours. Hardware schemes using external keys
> seem the most secure, and seem to not be crackable.
> ****
Hi Joe,
Here is what I did. The demo is almost exactly like the release, but...
The version number is cranked back one so that a release will write over
it as if a major upgrade. They don't have to uninstall it first.
Because it is all about the data, we restrict to opening only one named
project. Every time the app is closed a fresh copy of the mdb is copied
into the project folder.
When the software is started a checksum is run on the mdb to make sure
it is the shipped database, this means they can not modify the database
beyond one session without breaking the demo.
This keeps our #ifdef DEMO at a minimum and functionality at a max. It
would be easier for someone to steal the release than hack the demo, and
there we depend on the contract and copyright. Because our software is
used to create public documents, we have that edge too.
But what we produce is not something that someone would steal lightly.
It is a very small vertical business and everyone seems to know everyone
else. And we are part of the package with tech support.
There is only enough business to keep a ma and pa paying the bills. That
is why we have to wear all the hats ourselves. At that, I'm looking to
start a new venture with micros so we can get some eggs in another basket.
> As far as I know, virtualization kicks in only if you try to write it. Then things go
> really weird because of how the search is done on an open-for-read.
On common data, I don't know why, but even on the last windows 7 machine
our software created and reads and writes a file there without
triggering the UAC. This will be fixed along with my APP_DATA issue.
My understanding is that even if the user is logged on as admin, we
should not have those privileges.
Anyway, I'll report when I think I've got all this straight. I want to
thank you and everyone else for the feedback, it really helps.
Best, Dan.
Joseph M. Newcomer
****
I know that feeling; most of my consulting clients are small companies.
****
>
>> As far as I know, virtualization kicks in only if you try to write it. Then things go
>> really weird because of how the search is done on an open-for-read.
>
>On common data, I don't know why, but even on the last windows 7 machine
>our software created and reads and writes a file there without
>triggering the UAC. This will be fixed along with my APP_DATA issue.
****
I haven't hit anything that virtualizes yet, but that's mostly because I've been avoiding
doing anything that might trigger it for the last decaded. We first hit problems with
Win2K, and I've been careful ever since. So I'm not familiar with all the virtualization
issues. The basic idea is to avoid triggering UAC so older code runs, but it creates a
file that is truly local to the user, even though it appears to be in a shared folder.
****
>
>My understanding is that even if the user is logged on as admin, we
>should not have those privileges.
>
>Anyway, I'll report when I think I've got all this straight. I want to
>thank you and everyone else for the feedback, it really helps.
>
>Best, Dan.