By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,665 Members | 2,646 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,665 IT Pros & Developers. It's quick & easy.

Stashing Temp Files Under Documents and Settings\All Users?

P: n/a
Does his sound legal?

Somebody brought it up as an alternative to creating my temp DB under Documents
and Settings\User Name.

Sure seems simpler - conceptually identical to using C:\Temp in that no special
coding is required to tailor the location to each user.

But somehow it sounds like an end run - flaunting the spirit of the standard.
Also, on my PC, I notice that there is no ...\All Users\Local Settings
directory.
--
PeteCresswell
Apr 23 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
(PeteCresswell) wrote:
Does his sound legal?

Somebody brought it up as an alternative to creating my temp DB under
Documents and Settings\User Name.

Sure seems simpler - conceptually identical to using C:\Temp in that
no special coding is required to tailor the location to each user.

But somehow it sounds like an end run - flaunting the spirit of the
standard. Also, on my PC, I notice that there is no ...\All
Users\Local Settings directory.


I just use the folder where the MDE resides. The user obviously has appropriate
rights to that folder or he wouldn't be able to run the app and it is dead easy
to determine this path without an API call.

I fail to see why a temporary file "must" be created in a folder that has been
specificaly earmarked for temporary files. If the app folder is good enough for
Microsoft (LDB file) then it is good enough for me.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Apr 23 '06 #2

P: n/a
Per Rick Brandt:

I just use the folder where the MDE resides. The user obviously has appropriate
rights to that folder or he wouldn't be able to run the app and it is dead easy
to determine this path without an API call.


I used to think the same thing - using C:\Temp in my case.

But I think there's something about MS trying to lock down the root of C - not
all the time... but sometimes. It's like an ongoing work by MS, they haven't
gotten to full enforcement, but it seems tb coming..

Don't understand it very clearly, but it seems to explain a couple of instances
where I had to have the LAN admins intervene for some users who used my apps.
--
PeteCresswell
Apr 23 '06 #3

P: n/a
(PeteCresswell) wrote:
Per Rick Brandt:

I just use the folder where the MDE resides. The user obviously
has appropriate rights to that folder or he wouldn't be able to run
the app and it is dead easy to determine this path without an API
call.


I used to think the same thing - using C:\Temp in my case.

But I think there's something about MS trying to lock down the root
of C - not all the time... but sometimes. It's like an ongoing work
by MS, they haven't gotten to full enforcement, but it seems tb
coming..

Don't understand it very clearly, but it seems to explain a couple of
instances where I had to have the LAN admins intervene for some users
who used my apps.


But again, the folder where your app resides cannot be locked down or they
couldn't run it, so why not just use that folder?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Apr 23 '06 #4

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:Yn******************@newssvr11.news.prodigy.c om:
(PeteCresswell) wrote:
Does his sound legal?

Somebody brought it up as an alternative to creating my temp DB
under Documents and Settings\User Name.

Sure seems simpler - conceptually identical to using C:\Temp in
that no special coding is required to tailor the location to each
user.

But somehow it sounds like an end run - flaunting the spirit of
the standard. Also, on my PC, I notice that there is no ...\All
Users\Local Settings directory.


I just use the folder where the MDE resides. The user obviously
has appropriate rights to that folder or he wouldn't be able to
run the app and it is dead easy to determine this path without an
API call.

I fail to see why a temporary file "must" be created in a folder
that has been specificaly earmarked for temporary files. If the
app folder is good enough for Microsoft (LDB file) then it is good
enough for me.


But that's precisely the point! Choosing the location for the
MDB/MDE should follow the exact same rules Pete outlines for the
temp data.

Not, the %TEMP% folder, but the folder where your front end lives.
The reason is that because Access must have write access to the
front end file, you have to place it in a location that is
accessible to user-level Windows logons. The best place for that is
in the user's profile.

And on Windows Terminal Server, it's the only viable location, as
you would otherwise be sharing the front end between multiple users.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 23 '06 #5

P: n/a
"(PeteCresswell)" <x@y.Invalid> wrote in
news:6q********************************@4ax.com:
Per Rick Brandt:

I just use the folder where the MDE resides. The user obviously
has appropriate rights to that folder or he wouldn't be able to
run the app and it is dead easy to determine this path without an
API call.
I used to think the same thing - using C:\Temp in my case.

But I think there's something about MS trying to lock down the
root of C - not all the time... but sometimes. It's like an
ongoing work by MS, they haven't gotten to full enforcement, but
it seems tb coming..


No, it arrived in 1999. The reason most Access programmers don't
seem to know about it (I'm guessing) is that the default setup for a
standalone PC creates the main user logon as a member of the
machine's administrative group. In a default domain logon, that is
not the case -- user's are members of the Domain User's group, which
does not give them administrative permissions on their workstations.

The release of Windows 2000 was the point at which the system drive
was locked down (at least, the Windows and Program Files folders) --
that was 1999.

I know that one LAN where I do work was set up with the users being
members of the admin group so that their Win2K workstations were
running as admin. This was, I assume, because some software they
were running was not designed properly to run as a user-level logon.

There are programs still being released that have the problem. One
of those is QuickBooks, where the user has to be a member of at
least the Power Users group of the local workstation.

Here's the key point:

THAT IS BAD SOFTWARE DESIGN.

Here's as Wiki on the subject with lots of good information:

http://nonadmin.editme.com/

Let me stress that this is something all software developers should
have been accounting for starting with widespread adoption of
Windows 2000 (at the very least). WinXP and Win2K3 Server have made
the rules even stricter.
Don't understand it very clearly, but it seems to explain a couple
of instances where I had to have the LAN admins intervene for some
users who used my apps.


You're not alone. A number of large commercial software companies
still don't get it. Take, for instance, your AV software's program
updates. You're still forced to log on as an admin before it will
install an update to the program. The simple solution to that
problem is for the AV program update installer to invoke the RunAs
service to allow the user to run the installer as an admin without
forcing a full re-logon as a different user (not so ornerous on
WinXP with fast user switching as it is on any other version of
Windows).

The reason we have to deal with it in Access is because the front
end MDB file is treated by Access as a data file (needs WRITE
permission), when we are using it as a program file (which would
normally need only READ access). As long as Access front ends are
treated by Access as data 100% of the time, you'll always need to
install your Access front ends in user-writable storage space. The
place designed specifically for that is somewhere under the user's
profile.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 23 '06 #6

P: n/a
* Rick Brandt:
(PeteCresswell) wrote:
Does his sound legal?

Somebody brought it up as an alternative to creating my temp DB under
Documents and Settings\User Name.

Sure seems simpler - conceptually identical to using C:\Temp in that
no special coding is required to tailor the location to each user.

But somehow it sounds like an end run - flaunting the spirit of the
standard. Also, on my PC, I notice that there is no ...\All
Users\Local Settings directory.


I just use the folder where the MDE resides. The user obviously has appropriate
rights to that folder or he wouldn't be able to run the app and it is dead easy
to determine this path without an API call.

I fail to see why a temporary file "must" be created in a folder that has been
specificaly earmarked for temporary files. If the app folder is good enough for
Microsoft (LDB file) then it is good enough for me.


Yep. CurrentProject.Path works for me.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.
Apr 23 '06 #7

P: n/a
Per Rick Brandt:
But again, the folder where your app resides cannot be locked down or they
couldn't run it, so why not just use that folder?


My recollection of the occasional problems I've had includes the inability to
even download the app to C:\Temp.

I think David Fenton had is finger on it: Administrative Permissions.
--
PeteCresswell
Apr 24 '06 #8

P: n/a
Per David W. Fenton:
And on Windows Terminal Server, it's the only viable location, as
you would otherwise be sharing the front end between multiple users.


David, I think you just answered my other question (above...) about "Why not put
it under "All Users"...

Thanks.
--
PeteCresswell
Apr 24 '06 #9

P: n/a
On Sun, 23 Apr 2006 11:05:48 -0400, "(PeteCresswell)" <x@y.Invalid>
wrote:

Do not assume that there is a C:\TEMP, and not even that there is a
C-drive. Rather use Environ("TEMP").

-Tom.

Per Rick Brandt:

I just use the folder where the MDE resides. The user obviously has appropriate
rights to that folder or he wouldn't be able to run the app and it is dead easy
to determine this path without an API call.


I used to think the same thing - using C:\Temp in my case.

But I think there's something about MS trying to lock down the root of C - not
all the time... but sometimes. It's like an ongoing work by MS, they haven't
gotten to full enforcement, but it seems tb coming..

Don't understand it very clearly, but it seems to explain a couple of instances
where I had to have the LAN admins intervene for some users who used my apps.


Apr 24 '06 #10

P: n/a
"(PeteCresswell)" <x@y.Invalid> wrote in
news:ae********************************@4ax.com:
Per Rick Brandt:
But again, the folder where your app resides cannot be locked down
or they couldn't run it, so why not just use that folder?


My recollection of the occasional problems I've had includes the
inability to even download the app to C:\Temp.

I think David Fenton had is finger on it: Administrative
Permissions.


This is not some magical inside knowledge I have. It's perfectly
well documented and anyone who has even the most basic knowledge of
NTFS security and user management ought to be able to figure it out.

I think it's odd that an Access developer as knowledgable as you,
Pete, is seemingly so lacking in knowledge about such a basic and
important concept as Windows user security.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 24 '06 #11

P: n/a
Per David W. Fenton:
I think it's odd that an Access developer as knowledgable as you,
Pete, is seemingly so lacking in knowledge about such a basic and
important concept as Windows user security.


Easy: if it's not causing a problem, I don't go there.

Now it's causing a problem and I'm going there...
--
PeteCresswell
Apr 24 '06 #12

P: n/a
Per (PeteCresswell):
an Access developer as knowledgable as you,


I'm flattered.
Dunno if I'll be able to get my head through the door leaving work today...
--
PeteCresswell
Apr 24 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.