Can't write to CSIDL_COMMON_APPDATA on a customer's computer

A potential customer can't get my VB6 app to write files on his computer (XP). Every directory he tries is read only to my app. It's a huge corporation in Taiwan, so their security is high, and I have not yet gotten to talk to their IT folks.

My program defaults to save its history and temporary files to CSIDL_COMMON_APPDATA (using SHGetFolderPath, of course). I have not yet seen what directory this gets on his computer.

I will ask him to "right click on the EXE and run as administrator", but I need a long term solution.

What do I ask IT to do for me?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

SteveIT ManagerCommented:
Have you considered for testing, saving all history and files to a set folder on the C: drive e.g. c:\temp ?

Failling that it may be down to security and permissions - ask their IT to run it; i'd also find out what restrictions are in place in case there are other aspects of the app that may be affected either now or later on down the line.

Not a good place to save to.....

That value should be determined by this reg key....

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Value is "Common AppData"

Almost always is

"C:\Documents and Settings\All Users\Application Data"

You should be able to grant Users "Modify" rights to this folder, but that opens the potential for infections when something can write to the AllUsers path. Especially the rogues that are flying around now......

SteveIT ManagerCommented:
Only save to for testing not in production, just to ensure it works.
pfiekowskyAuthor Commented:
I found the solution--
1. Use a user drive--the customer had a K: drive with full permission.

2. Don't use the CSIDL_COMMON_APPDATA ("C:\Documents and Settings\All Users\Application Data") at all, because that's totally locked down.

The funny part was that I tested the file, in addition to checking its ReadOnly attribute, by writing the current time, and reading it back, to see if it read back what I wrote. This appeared to fail, when it actually worked because I did (in VB)
if strWritten <> strRead then 'must be readonly.

The time had the Chinese character for "pm" in it, and that string compare failed. I changed it to
if StrComp(strWritten, strRead) = 0
which worked, meaning that the file could be read.

Bottom line: just because Windows says to use CSIDL_COMMON_APPDATA, it's only a suggestion. The user must decide--their IT department may have locked down all of C:\.

Thank you all for your suggestions

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
OS Security

From novice to tech pro — start learning today.