XP Pro Users - Please help with shared data test

Hi, I'm trying to work out if XP Home (which I have) is different from XP Pro with regards to folders created in: C:\Documents and Settings\All Users\Application Data

If you have XP Pro, I wondered if you can run some tests for me, thanks!

TEST1:

1) download this: http://www.greyaliengames.com/aotmg/aotmg106.zip

2) Make sure you are logged on as administrator

3) In case you've run AOTMG before, first go to C:\Documents and Settings\All Users\Application Data\Grey Alien Games\AOTMG and delete the folder. (Note that Application Data is a hidden folder, so you may need to click Tools/Folder Options/View/Show Hidden Files and Folders.

4) Unzip AOTMG106 to the C Drive somewhere suitable (not on your Desktop).

5) Run AOTMG.exe. It should work fine. If you check, you'll see that's it's made a folder called C:\Documents and Settings\All Users\Application Data\Grey Alien Games\AOTMG with some dynamic data in it.

6) Change to a non-admin user.

7) Run the game again. It should work fine as the data is shared for all users with some special code. This is NOT working on one user's PC from Portugal and I can't figure out why! It works fine on mine and lots of other PCs.

TEST 2:

1) download this: http://www.greyaliengames.com/aotmg/aotmgtest.zip

2) Make sure you are logged on as administrator

3) This time you MUST delete C:\Documents and Settings\All Users\Application Data\Grey Alien Games\AOTMG and all the contents. (Note that Application Data is a hidden folder, so you may need to click Tools/Folder Options/View/Show Hidden Files and Folders.

4) Go to your previous installation of AOTMG and copy in the exe from the aotmgtest.zip file overwriting the old exe.

5) Run the exe. It should work.

6) Change to a non-admin user.

7) Run the game again. It should NOT work. You should get an error about an ini file not being able to write. That's what I get on mine anyway.

Please report back your results. I really appreciate your help with this, thanks!

I get the exact results as described above
That is,


TEST 1
Admin -> Works
Guest -> Works

TEST 2
Admin -> Works
Guest -> Fails (Cannot write to blahblah file)

Same as Jim

OK thanks, really appreciate your help. Your results were what I expected. Now to figure out why this person's PC is different.

Hey if anyone else has XP Pro on a non English-language setup, it would be really great if you could run this test for me, thanks!

TEST 1
Admin -> Works
Guest -> Works

TEST 2
Admin -> Works
Guest -> Error: Failed to write to 'C:\Documents and Settings\All Users\Dati applicazioni\Grey Alien Games... '

XP Pro 2002 SP 2

OK thanks! So that's the Italian version of Windows tested :-)

XP Pro in that manner should work quite similar to how Vista works when it comes to right management and writing to the application data folder.

And on the not working: Ask the user from portugal if the paths for application data has some special char in and I thought the BM core does only support US AScii (0-127 instead of 0-255 which is ASCII)

The BM core stores strings in unicode format, and leaves the unicode format in every print or console operation (even when the console doesn't support unicode character set), but files and folders names are internally managed as ANSI in some windows distros. Depending on the country and the windows build. I'm not sure if this will be the problem.

Thats exactly the problem.
BM Strings are unicode
But not the stuff that the internal core uses which is not String based. This was officially confirmed by BRL.
The internal core is not unicode compatible -> BM will not work with foldernames that are non-ANSI even thought its nowhere mentioned that BM is english only (because it is not even ascii compliant which is a joke in 2008 where the OS are unicode compliant)

Well on the user's PC who is experiencing problems, it works on the admin account but not on the guest account (so this infers that the paths are fine and don't contain illegal chars). It's as if the special code to share the folder is failing on his PC despite working on all others.

Interesting about the ANSI chars users in the core. I was thinking that perhaps if the path had non-ANSI chars it might get garbled when passed into the Windows function which shares the path, but it seems to be standard ANSI chars. Here's the path on his PC:

C:\Documents and Settings\All users\Dados de aplicativos\Grey Alien Games/

As you can see there are no funny characters used there unless he missed them out when typing the name? Anyone know portugese?

You could ask him if he reduced the rights of his user account. XP Pro offers you far more indepth setting possibilities.
As well it could be that he has some kind of security application that interfers or "catches" the call you do through appi.

I would assume thats more something towards the first one, that Windows just does not give it the right to do it when you use your WinAPI calls.

Good thing is that the solution most likely will work in the higher Vista Editions as well on user accounts with reduced rights.

I asked him that and he says he didn't alter anything. I also wondered if it was a security program somehow blocking stuff. It's weird. I may have to give in - gasp!

The code seems to work on Vista, no one has reported any issues yet, but it probably hasn't been used on as many vista PCs.

I don't know it this could be useful, but I made this little program to test on my computer

Framework BRL.BASIC
Import BRL.Retro

Print "USER PROFILE: "+getenv_("USERPROFILE")
Print "USER NAME   : "+getenv_("USERNAME")
Print 
Print "USER OS     : "+getenv_("OS")
Print "USER TEMP   : "+getenv_("TEMP")
Print "USER TMP    : "+getenv_("TMP")
Print
Print "ALL USER    : "+GETENV_("ALLUSERPROFILES")
Print "App data    : "+getenv_("APPDATA")
Print
Print "Processor arch: "+getenv_("PROCESSOR_ARCHITECTURE")
Print "Computer name : "+getenv_("COMPUTERNAME")
Print "Home drive    : "+getenv_("HOMEDRIVE")
Print "Home path     : "+getenv_("HOMEPATH")
Print "Program files : "+getenv_("PROGRAMFILES")
Local username$=getenv_("USERNAME")
Local MYDATA$=getenv_("APPDATA")+"\MyFolder"
Local r:Int=CreateDir(mydata)
If r
	Print "Folder: "+mydata
	rr=CreateFile(mydata+"\test_file_"+username+".txt")
	If rr Print "file created..."
End If

'App data    : C:\Documents and Settings\degac\Dati applicazioni
'try to write here: C:\Documents and Settings\All users\Dati applicazioni

Local newpath$=Replace(mydata,username,"All Users")
Print "New path: "+newpath

Local r2:Int=CreateDir(newpath)
If r2
	Print "Folder: "+newpath
	rr2=CreateFile(newpath+"\test_file_newpath_"+username+".txt")
	If rr2 Print "file created..."
End If

Basically it creates a folder 'myfolder' under (user_name)

and in this folder it creates a file test_file.txt.
Then it creates a new folder in 'all users' and a new file test_file_newpath.txt in


I have tested with 2 users: degac (administrator) and test (normal user without admin privileges) under XP Pro
For every users I disconnected and logged in with the other one.
It works. I can create both the files under user_name\Dati applicazioni\MyFolder without errors.

That's strange as if a file already exists in the folder having been created by the admin user it should be read only when you logon as the other user and then the createfile command will fail because it's not allowed to overwrite it.

Well, I can access the 'All users' folder as Test user, open the file, write on it, save it.
I cant' access to DEGAC (admin user) folder - I get an error.

Hmm this is curious because on my PC (and the ones who ran the test, which includes yourself), the test user cannot overwrite the ini file because it's "read only" when it's created by the first admin user. I don't understand what your code above is doing different (haven't tested it yet mind you).

I changed a little the program

Framework BRL.BASIC
Import BRL.Retro
Import BRL.PolledInput


Local username$=getenv_("USERNAME")
Local MYDATA$=getenv_("APPDATA")+"\MyFolder"
Local r:Int=CreateDir(mydata)
If r
	Print "Folder: "+mydata
	rr=CreateFile(mydata+"\test_file_"+username+".txt")
	If rr Print "file created...test_file_"+username+".txt"
	
	rr0=CreateFile(mydata+"\test_file.txt")
	If rr0 Print "file created...test_file.txt in "+mydata
End If

'App data    : C:\Documents and Settings\degac\Dati applicazioni
'try to write here: C:\Documents and Settings\All users\Dati applicazioni

Local newpath$=Replace(mydata,username,"All Users")
Print "New path: "+newpath

Local r2:Int=CreateDir(newpath)
If r2
	Print "Folder: "+newpath
	rr2=CreateFile(newpath+"\test_file_ALLUSER.txt")
	If rr2 Print "file created...test_file_ALLUSER.txt"
	
End If

WaitKey

Compile it with 'Build GUI App' not selected (to view the output window).
The program writes (as admin or as simple user) a file in

I stared as TEST user, the program creates the files. I opened the file in All Users...and I wrote in it 'from test user'.
Switched to ADMIN user, I can read the modified file.
Run the program.
Now the file 'Test_file_ALLUSER.txt' is blank. I wrote in it 'From ADMIN',
switched again to TEST user, run the program, Test_file_ALLUSER.txt - rewritten & blank.

I dont' know it this is normal or not - but I can access the ALL USER folder and write to the file, BUT I can't copy a .exe file from D: to C:\ as TEST user.