Acquire User's Roaming Folder

[Superfreak3]

We have an .exe that fires off to read an .ini file to grab some
version information, which is in turn used to determine if our
automated update process should be fired off. The ini file we are
trying to find is located in

Users\<UserA>\AppData\Roaming\MyCompany\MyApp\

UserA is a Standard User with UAC enabled. When I attempt to fire
the .exe, I am prompted for Credentials of an Administrator. The
credentials applied are for Administrator UserB.

After applying the proper credentials, the application indicates that
the Server Share (ini location) could not be found. After doing some
debugging via log writes, I see that, after applying credentials, it
is looking in the User location of UserB (Admin used to apply
credentials). Instead of looking to the logged on user's path

I'm using SHGetSpecialFolderPath(0, Buf, CSIDL_APPDATA, 0); to get the
user folder if that leads to anything.

Is there any way in VISTA to get this to work properly for the logged
on Standard user (UserA) instead of looking to the user whose
credentials were applied to allow our .exe's execution?

If this is confusing and more clarification is needed, PLEASE let me
know and I will provide any information needed!

THANKS IN ADVANCE!!

 

[Andrew McLaren]

Hi Matt,

A couple of ideas spring to mind.

Firstly, CSIDL_APPDATA is a pretty old value, which really applies more to
"Windows 95"-style shells (that is, pre-Internet Explorer 4.0). On Windows
2000, XP, Server 2003 and Vista, you'll want to use CSIDL_LOCAL_APPDATA
instead. See:
http://msdn2.microsoft.com/en-us/library/ms649274.aspx
for details. This might not solve your problem in a single stroke, but it
could avoid some issues. By default, Standard Users have read/write
permissions to CSIDL_LOCAL_APPDATA.

Secondly, you can control whether the app will prompt for UAC elevation by
adding a manifest. If your manifest includes the line:

requestedExecutionLevel level="asInvoker" uiAccess="false"

.... then the app will run as the invoking user (ie a standard user) and will
not prompt for elevation; if read/write access is denied, then the app will
just report an "access denied" error, same as on XP.

A couple of handy links in MSDN to find more detail on manifests, etc:

Windows Vista Application Development Requirements for User Account Control
Compatibility
http://msdn2.microsoft.com/en-us/library/bb530410.aspx

User Account Control for Game Developers
http://msdn2.microsoft.com/en-us/library/bb206295.aspx
(This concise, well-written summary is great for all developers, not just
games guys!)

Microsoft did have a "Standard User Analyzer" tool which you could download,
to investigate problems like this. This tool has now been moved into the
Application Compatibility Toolkit -
Microsoft Application Compatibility Toolkit 5.0
http://www.microsoft.com/downloads/...e9-b581-47b0-b45e-492dd6da2971&DisplayLang=en

Hope it helps,