Re: Stashing Temp Files Under Documents and Settings\All Users?
- From: "David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 23 Apr 2006 13:58:33 -0500
"(PeteCresswell)" <x@xxxxxxxxx> wrote in
news:6q5n42p296hkjvfg9j0k89fuujbjbl6r54@xxxxxxx:
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/
.
- References:
- Stashing Temp Files Under Documents and Settings\All Users?
- From: (PeteCresswell)
- Re: Stashing Temp Files Under Documents and Settings\All Users?
- From: Rick Brandt
- Re: Stashing Temp Files Under Documents and Settings\All Users?
- From: (PeteCresswell)
- Stashing Temp Files Under Documents and Settings\All Users?
- Prev by Date: Re: Stashing Temp Files Under Documents and Settings\All Users?
- Next by Date: Re: Access 97 vs. newer versions
- Previous by thread: Re: Stashing Temp Files Under Documents and Settings\All Users?
- Next by thread: Re: Stashing Temp Files Under Documents and Settings\All Users?
- Index(es):
Relevant Pages
|
