access denied on win7 while compiling
BlitzMax Forums/BlitzMax Programming/access denied on win7 while compiling
| ||
| Every now and then, when I compile/run a program I get an access denied message (under Windows 7). Hitting F5 a second time usually works, though. I have administrator rights. Anyone know what's going on here? It's no big inconvenience, but still a puzzler. I even get out of memory errors occasionally - also when compiling (I have 4 gigs), but again, hitting F5 a second time usually works. Any ideas? Thanks! Russell |
| ||
| Administrator rights does not provide write permissions for all folders in the system. you shoud disable also the UAC or compile/run things always from outside the program files folder. |
| ||
| It could also be that a previous instance of the program hasn't quite finished terminating itself (even after the open window has closed), which means that there still is a file lock by the operating system and you can't yet create a new executable by that name: "access denied" Are you sure that the "stop" button in the MaxIDE is not still active (red) when you try to (re)compile the program? If it is, that would indicate that a previous instance is still running. Also, if it is UAC interfering, you don't necessarily have to disable it altogether if you like having it -- reinstalling blitzmax outside of the program files folder will also prevent it from interfering. (the latest versions install to c:\blitzmax for exactly that reason) |
| ||
| The same here using Blide, Windows7 and c:\Blitzmax as path. |
| ||
| I ran into similar problems when I first installed vista. The reason for the problems was that I had UAC turned on. UAC restricts certains access to the Root and also the program files folder. Turning UAC worked magic. Just installed Blide on Win7 and I believe that it installed on c:\Blitzmax or in c:\Program Files(x86). Turned off UAC, and had no problems at all compiling. |
| ||
| I get it too but it doesn't happen often enough to irritate me. Windows 7, UAC off. Blitzmax is at C:\BlitzMax. |
| ||
| BLIde can safelly be installed in Program files (on windows 32 bits) and on Program files(86) on windows 64 bits. It will not affect BlitzMax performance or anything, as BLIde is not storing or using the Program files folder for anything, all BLIde storage is done in the BLIde Framework folder in the Documents folder of the BLIde user. BUT BlitzMax should be installed outside the Program Files folder to avoid this. If you install it at, as instance c:\blitzmax you should not get any issues at all. It could be related to the program being still running, or your AV being still analizing the EXE. I've seen this on computers with Norton AV |
| ||
| It happens maybe every 20th compile or so: Not really enough to be a irritation. And immediately clicking compile/run again fixes the problem. I don't think it's UAC (it would be active all the time, not sporadically). Similar topic: I wonder how hard it would be for BMax to compile native 64 bit code for 64 bit systems like mine? How much of a gain would there be? I guess that would depend on the type of program being created. Russell |
| ||
| I wonder how hard it would be for BMax to compile native 64 bit code for 64 bit systems like mine? Given that it currently generates 32bit assembler, I'd imagine it would be quite hard indeed. |
| ||
| It's happening to me nearly half of the time! It's not related to UAC because I disabled this thing the very first day I installed Windows 7. It wasn't happening at the very first moments but now that my system is slower (mainly because of the 1Go DDR) it's very often! It's simply like xlsior said the application is lock, sometime very long after it's execution, and you are not allowed to produce/remove/update the execution file. I just rebuild a second time and generally after that it's OK. OK but annoying when build time are long. |
| ||
| That on the other hand sounds like a consequence of low RAM (1GB + win7 is 2 GB less than there should be) in conjunction with antivirus and similar as they will take quite some time in such an environment to fullfill their realtime checking. the rebuild goes faster cause the same code comes in again and should pass pretty much directly. Also the folder cache will be in the right folder already |
   |