Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #2293 > unrolled thread

File Location

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  File Location HarryC <h.caulkett@comcast.net> - 2016-12-03 10:28 -0500
    Re: File Location GS <gs@v.invalid> - 2016-12-06 00:39 -0500
      Re: File Location HarryC <h.caulkett@comcast.net> - 2016-12-06 07:10 -0500
      Re: File Location HarryC <h.caulkett@comcast.net> - 2016-12-06 08:25 -0500
        Re: File Location Jim Mack <no-ube-uce@mdxi.com> - 2016-12-06 09:57 -0500
          Re: File Location HarryC <h.caulkett@comcast.net> - 2016-12-06 15:45 -0500
        Re: File Location GS <gs@v.invalid> - 2016-12-06 15:02 -0500
          Re: File Location HarryC <h.caulkett@comcast.net> - 2016-12-06 20:41 -0500
            Re: File Location Jim Mack <no-ube-uce@mdxi.com> - 2016-12-06 21:43 -0500
            Re: File Location GS <gs@v.invalid> - 2016-12-06 23:49 -0500
              Re: File Location HarryC <h.caulkett@comcast.net> - 2016-12-07 05:04 -0500
                Re: File Location Jim Mack <no-ube-uce@mdxi.com> - 2016-12-07 07:30 -0500

#2293 — File Location

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

[toc] | [next] | [standalone]

#2303

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!

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#2304

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

Thanks Gary

>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!

[toc] | [prev] | [next] | [standalone]

#2305

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.

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

>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!

[toc] | [prev] | [next] | [standalone]

#2306

On 12/6/2016 8:25 AM, HarryC wrote:
>
> 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.

-- 
       Jim

[toc] | [prev] | [next] | [standalone]

#2308

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

On Tue, 6 Dec 2016 09:57:18 -0500, Jim Mack <no-ube-uce@mdxi.com>
wrote:

>On 12/6/2016 8:25 AM, HarryC wrote:
>>
>> 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.

[toc] | [prev] | [next] | [standalone]

#2307

> 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!

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#2309

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

On Tue, 06 Dec 2016 15:02:17 -0500, GS <gs@v.invalid> wrote:

>> 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!

[toc] | [prev] | [next] | [standalone]

#2310

On 12/6/2016 8:41 PM, HarryC wrote:
> 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.

-- 
       Jim

[toc] | [prev] | [next] | [standalone]

#2311

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.

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#2312

Ok - Once again thanks guys



On Tue, 06 Dec 2016 23:49:38 -0500, GS <gs@v.invalid> wrote:

>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.

[toc] | [prev] | [next] | [standalone]

#2313

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

On 12/7/2016 5:04 AM, HarryC wrote:
> Ok - Once again thanks guys
>
>
>
> On Tue, 06 Dec 2016 23:49:38 -0500, GS <gs@v.invalid> wrote:
>
>> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web