Vista Error with WriteFile?
BlitzMax Forums/BlitzMax Beginners Area/Vista Error with WriteFile?
| ||
The following Test Code hangs the app for me in Vista and doesn't write anything to the file.
SuperStrict
Graphics 800, 600
Global Array:Int[10, 10]
For Local x:Int = 0 Until 10
For Local y:Int = 0 Until 10
Array[x, y]= Rand(0, 20)
Next
Next
Global filetoWrite:String = CreateFile("File.txt")
Global FileStream:TStream = WriteFile(FileToWrite)
For Local y:Int = 0 Until 10
For Local x:Int = 0 Until 10
WriteInt FileStream, Array[x, y]
Next
Next
CloseFile FileStream
While Not KeyHit(KEY_ESCAPE)
Cls
Flip
Wend |
| ||
| use WriteFile("File.txt") instead of Writefile(FileToWrite) CreateFile(filename) sends True value if file is created. or you can just use WriteStream("File.txt") and that create file if not exists. |
| ||
| Thank You Zeke. That works perfectly now. :) |
| ||
| and stop breaking Windows Access Guidelines. You are NOT allowed to write somewhere outside the userdata folder and the own files folder of the user! everything else will be blocked |
| ||
Well the directories in my app are structured like this.
Game( DIR):
GFX:(DIR)
UserMaps(DIR):
I'm writing to the usermaps folder inside the main game directory and it appears to be working fine. I have UAC turned on also for testing purposes. This shouldn't be a problem (writing to a folder in the main game folder), should it? |
| ||
| Start it in a user account and see make it boom. this holds for XP and vista if you want to programm stuff on windows, it would be a vice decision to read microsofts guidelines I think ... otherwise you will start like others and blame MS for your ignorance in the end ... |
| ||
| yeah it is a problem. Checkout the big Vista thread I've got in General Discussion. Have you actually looked in your sub folder, I bet the file hasn't written to it. It will have been "virtualised" by Vista and written elsewhere. If you were to change users, they wouldn't see any of the usermaps created by the first user. |
| ||
| Which is a good thing if you don't want your little sister trashing them. |
| ||
| It's a bad thing for family-based casual games where different users log on to Vista and wish to share a high score table or other data like a settings file. |
| ||
| Well, I have UAC turned on and I've succesfully created 70 maps without fail. All have been written to the usermaps folder. I thought I read somewhere that an application has only the permission to write to the folder it's in and any sub folders. I'll take a look at the vista thread. :) |
| ||
| on admin account you can write to nearly anything (beside program files and windows without allowing it through the UAC dialog I think) Grey: still don't understand why the stuff gets trashed when you save to the common folder. Did you try out to use an installer to create empty files for it, so it is not virtualized? thats how it is commonly done, as the install must happen in admin anyway (for a multi user install) so that isn't a problem. |
| ||
| I created a non admin account in Vista and switched to that account. UAC is turned on and I was still able to save maps to my usermaps folder without fail while playing the game. This is fine for me then as I want to keep the maps in the usermaps folder and not somewhere else. |
| ||
| on my laptop's fresh Vista install with UAC enabled, with an admin OR non-admin account any writes to a subfolder of the game appear to work (i.e. game doesn't crash) but when looking in the actual subfolder, they are not there. They have been virtualised to a weird hidden folder for the currently logged on user (see other Vista thread for more details) Dreamora: Nothing get's trashed it's just written somewhere else (when virutalisation occurs) so if you swap users you won't see the data that was written before. Yes, if you write to Common App Data, all users can read it but guess what, only the original admin user can write to it UNLESS the installer had elevated rights and set those writes (for anyone to write) to the game sub-folder in Common App Data. This requires special knowledge of installer script settings. Amon, you say it works fine, which is weird. Someone else said stuff was fine on their Vista setup too but this is not how the MSDN site says it works and not my experience too. If it works for you great, but if you want to spread the exe when it's done, it may fail on other PCs..... |
| ||
| Well, I'm not going to question you guys as you know more than me. I've looked at the Vista thread and there appears to be no solution yet. If you guys can't find a solution I've got sod all hope of finding one myself. Is this going to be a major problem? Basically I need it to work as I want the maps created by users to be available to all users. |
| ||
| Grey: Nobody ever said it would be a simple thing to get this kind of stuff working. The best page I found on MSDN on this topic was http://support.microsoft.com/?scid=kb%3Ben-us%3B927387&x=13&y=11 but I assume that the single place to really find usefull information is the Vista Platform SDK ... |
| ||
| Yep, it's not simple. The page sums up what I said about virutalisation already: File and registry virtualization helps users who have restricted access to the registry and to the file system write to these protected areas. Virtualization creates a "per user" copy and then redirects successive data operations. For example, assume that an application is running under a Limited User Account or under accounts that require User Account Control permissions. When this application writes to a system location, such as to the %programfiles% folder, Windows Vista redirects write operations and read operations to a user-specific location in the user’s profile folder (%localappdata%\VirtualStore). By default, this location is C:\Users\User_name\AppData\Local\VirtualStore\Program Files\Application_name. Registry virtualization works similarly but applies to registry keys under the HKEY_LOCAL_MACHINE\SOFTWARE subtree. The keys and data under this subtree are redirected to the HKEY_CURRENT_USER\Software\Classes\VirtualStore subkey. Amon. You can't get it to work like that in Vista unless your installer program uses a special script to give your data folder special permissions. Also the data folder must be in a special location (COMMON_APPDATA is the const that returns the correct path). |
   |