473,320 Members | 1,876 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Stashing Temp Files Under Documents and Settings\All Users?

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
12 3020
(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
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
(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
"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
"(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
* 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
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
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
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
"(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
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
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: dspohn | last post by:
I am designing a document management system (DMS). The files are stored in a directory on the webserver. The filenames for the documents are stored in a MySQL database. The DMS will track...
3
by: Adam Parkin | last post by:
I was wondering, what's the "proper" (hehe) way to retrieve the system's temp directory in VB 6. Like for example, on my Windows XP machine the temp directory that is used by programs for their...
4
by: Samuel | last post by:
I am building an web application that will be hosted on load balanced servers (multiple front and one backen db). The application will have to allow users to upload files onto the server. For...
0
by: ACFalcon | last post by:
The Temp Folder for the ASPNET user (C:\Documents and Settings\<<Server>>\ASPNET\Local Settings\Temp) has some large files that haven't been modified for months, and I was wondering if removing...
17
by: Jon Ole Hedne | last post by:
I have worked on this problem some hours now (read many-many...), and I can't solve it: In vba-code I create a table with Connection.Execute, and add some data to it. This table is saved in the...
2
by: Craig | last post by:
I have a folder within my web application that holds a bunch of word documents. I have security setup to use forms authentication. If I try and access a .aspx page that is not listed in my...
3
by: tigrrgrr42 | last post by:
I am working(vb.net03and05) with word documents stored in a sql db and I am currently bringing them from a byte array into a temp file to pop into word and make word do its thing as a com object. ...
2
by: queanbeyan | last post by:
Hi I have found that many of my potential users of my application are not able to write to their program files directory on C:\program files, however they have access to 'My documents'. i...
4
by: anthony | last post by:
Is there a way, using code, to copy files from one location to another? I have a table with the filenames so, having defined the path to the folder, I then need to copy the relevant files and paste...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.