XP Pro Users - Please help with shared data test
BlitzMax Forums/BlitzMax Programming/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) C:\Documents and Settings\degac\Dati applicazioni\MyFolder 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 C:\Documents and Settings\All Users\Dati applicazioni\MyFolder 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. Building _OS_INFO Executing:_OS_INFO.exe USER PROFILE: C:\Documents and Settings\degac USER NAME : degac USER OS : Windows_NT USER TEMP : C:\DOCUME~1\degac\IMPOST~1\Temp USER TMP : C:\DOCUME~1\degac\IMPOST~1\Temp ALL USER : App data : C:\Documents and Settings\degac\Dati applicazioni Processor arch: x86 Computer name : AMIGA Home drive : C: Home path : \Documents and Settings\degac Program files : C:\Programmi Folder: C:\Documents and Settings\degac\Dati applicazioni\MyFolder file created... New path: C:\Documents and Settings\All Users\Dati applicazioni\MyFolder Folder: C:\Documents and Settings\All Users\Dati applicazioni\MyFolder file created... Process complete |
| ||
| 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 C:\Documents and Settings\All users\Dati applicazioni\MyFolder\test_file_ALLUSER.txt 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. |
   |