File Location

[HarryC]

I have a VB app that once installed it creates an Access database in a
directoy below the directory where the program is installed.
Everything worked fine untill some of my clients updated windows and
then the os decided it wanted the data file (.mdb) located deep in the
user directory. When my clients would use the program everything
seemed to work except when they exited the program and came back in
none of the new data changes were saved. I believe that the new
location may have been but not the original. The work around that i
used was to have them install the program in the root and not the
Program Files directory the data stayed where it was originally put.
I remember reading about MS changing where THEY wanted the data
I can't remember all the details. So can anyone tell me where an
article on this is. I would much rather have them install the program
using all the default settings.
Also - could it be fixed if the extension on the access file was
changed from .mdb to something else like .xxx would that stop the os
from knowing it's a data file?

Thanks
HarryC

[GS]

Hhm.., Win10 perhaps? So annoying!

I use "app.dat" under the app folder in a subfolder named "UserData".
My installer sets up folder permissions during setup. So far this works
as expected!

[HarryC]

On Tue, 06 Dec 2016 00:39:38 -0500, GS <***@v.invalid> wrote:

Thanks Gary

Post by GS
Hhm.., Win10 perhaps? So annoying!
I use "app.dat" under the app folder in a subfolder named "UserData".
My installer sets up folder permissions during setup. So far this works
as expected!

[HarryC]

Gary,
While I'm thinking about this. My program on the initial run looks to
see if the data file(s) exist. If they don't then it creates all the
sub-directories below where the program resides. At some point the OS
then changes\copies the .mdb files and puts them (I think) into the
user directory. When they start the program again it opens the
original file but makes the changes\updates to the one down in the
user directory, then it looks like the changes were nver saved to the
user.As long as the program is running the updates\changes stay. This
is why I asked if changing the file extenion to something other than
.mdb the OS won't recognize the file as a data file and leave it
alone.

Post by GS
Hhm.., Win10 perhaps? So annoying!
I use "app.dat" under the app folder in a subfolder named "UserData".
My installer sets up folder permissions during setup. So far this works
as expected!

[Jim Mack]

Post by HarryC
Gary,
While I'm thinking about this. My program on the initial run looks to
see if the data file(s) exist. If they don't then it creates all the
sub-directories below where the program resides. At some point the OS
then changes\copies the .mdb files and puts them (I think) into the
user directory. When they start the program again it opens the
original file but makes the changes\updates to the one down in the
user directory, then it looks like the changes were nver saved to the
user.As long as the program is running the updates\changes stay. This
is why I asked if changing the file extenion to something other than
.mdb the OS won't recognize the file as a data file and leave it
alone.

It has nothing to do with the file extension. Under Windows UAC (User
Account Control), your program simply doesn't have write access to files
under C:\Program Files or any other system location. But since so many
older programs assumed full access, UAC instead silently redirects such
writes to a virtualized store in the user's own directory.


https://www.symantec.com/connect/articles/folder-virtualization-concepts-windows-vista

You can't control this on behalf of your users, it's all down to their
own UAC settings and Windows itself. Better you should learn and follow
the rules, and avoid all this.

[HarryC]

Ok guys thanks - Jim thanks for the link.
Its always good to learn.

Post by Jim Mack

Post by HarryC
Gary,
While I'm thinking about this. My program on the initial run looks to
see if the data file(s) exist. If they don't then it creates all the
sub-directories below where the program resides. At some point the OS
then changes\copies the .mdb files and puts them (I think) into the
user directory. When they start the program again it opens the
original file but makes the changes\updates to the one down in the
user directory, then it looks like the changes were nver saved to the
user.As long as the program is running the updates\changes stay. This
is why I asked if changing the file extenion to something other than
.mdb the OS won't recognize the file as a data file and leave it
alone.

It has nothing to do with the file extension. Under Windows UAC (User
Account Control), your program simply doesn't have write access to files
under C:\Program Files or any other system location. But since so many
older programs assumed full access, UAC instead silently redirects such
writes to a virtualized store in the user's own directory.
https://www.symantec.com/connect/articles/folder-virtualization-concepts-windows-vista
You can't control this on behalf of your users, it's all down to their
own UAC settings and Windows itself. Better you should learn and follow
the rules, and avoid all this.

[GS]

Post by HarryC
Gary,
While I'm thinking about this. My program on the initial run looks to
see if the data file(s) exist. If they don't then it creates all the
sub-directories below where the program resides. At some point the OS
then changes\copies the .mdb files and puts them (I think) into the
user directory. When they start the program again it opens the
original file but makes the changes\updates to the one down in the
user directory, then it looks like the changes were nver saved to the
user.As long as the program is running the updates\changes stay.
This is why I asked if changing the file extenion to something other
than .mdb the OS won't recognize the file as a data file and leave it
alone.

I agree with Jim's reply! Note that I mention my installer *sets folder
permissions* for the target install folder (and its subfolders).

Tough call as to where you install to and where your app files are
stored but means you have to disburse your files. Things were nicer
when we could keep everything in one place, and so this is my
preference and is why my installer sets folder permissions. (Mostly
because they are portable -can be run from a memstik- and so do not use
the Registry to store settings. Makes things simple when everything is
in one folder!)

The installer also only replaces certain app files if they don't exist;
-its the app's job to manage user data files it creates!

[HarryC]

I hate to keep beinbg a pain, but ..
What about the Windows [ ProgramData ] directory.
If the program\app is installed as an Administrator into the default
directory then create and use the data files in the [ ProgramData ]
directory. I can live with the program\app being installed anywhere I
just need to know that the correct data file is being updated and
where it's at.




Just to let the installer install the program\app in the default
location and then location

Post by GS

Post by HarryC
Gary,
While I'm thinking about this. My program on the initial run looks to
see if the data file(s) exist. If they don't then it creates all the
sub-directories below where the program resides. At some point the OS
then changes\copies the .mdb files and puts them (I think) into the
user directory. When they start the program again it opens the
original file but makes the changes\updates to the one down in the
user directory, then it looks like the changes were nver saved to the
user.As long as the program is running the updates\changes stay.
This is why I asked if changing the file extenion to something other
than .mdb the OS won't recognize the file as a data file and leave it
alone.

I agree with Jim's reply! Note that I mention my installer *sets folder
permissions* for the target install folder (and its subfolders).
Tough call as to where you install to and where your app files are
stored but means you have to disburse your files. Things were nicer
when we could keep everything in one place, and so this is my
preference and is why my installer sets folder permissions. (Mostly
because they are portable -can be run from a memstik- and so do not use
the Registry to store settings. Makes things simple when everything is
in one folder!)
The installer also only replaces certain app files if they don't exist;
-its the app's job to manage user data files it creates!

[Jim Mack]

Post by HarryC
I hate to keep beinbg a pain, but ..
What about the Windows [ ProgramData ] directory.
If the program\app is installed as an Administrator into the default
directory then create and use the data files in the [ ProgramData ]
directory. I can live with the program\app being installed anywhere I
just need to know that the correct data file is being updated and
where it's at.

At install time, create a folder in the current user's AppData folder

C:\Users\[Your User]\AppData\Local\[Your Program]\

That's where you should install and maintain the data files. Any decent
installer (like Inno Setup) should make this simple and foolproof.

[GS]

In additioon to Jim's counsel.., the user profile 'AppData' folder
allows modifypermission for thee user. Also, in the event of more than
1 user on the maxhine, work with the 'default' user's AppData folder so
all users edit the same data file.

[HarryC]

Ok - Once again thanks guys

Post by GS
In additioon to Jim's counsel.., the user profile 'AppData' folder
allows modifypermission for thee user. Also, in the event of more than
1 user on the maxhine, work with the 'default' user's AppData folder so
all users edit the same data file.

[Jim Mack]

Also, to make it more transparent you can have the installer create a
link to the data folder and place that in your application folder. The
user then doesn't have to root around to find the file (if that's even
needed).
--
Jim

Post by HarryC
Ok - Once again thanks guys

Post by GS
In additioon to Jim's counsel.., the user profile 'AppData' folder
allows modifypermission for thee user. Also, in the event of more than
1 user on the maxhine, work with the 'default' user's AppData folder so
all users edit the same data file.