Administrative Permission ?
#1
Posted 02 June 2012 - 04:30 PM
I could not understand the reason of the error. Is this a WinBuilder bug? Am I wrong? Kind regards
http://www.maxrealqn...eo/Why/Why.html
#2
Posted 03 June 2012 - 06:36 AM
You have denied permissions for yourself...
SetACL works with this code... (Beware, this code also delete all users permissions)
SetACL.exe -on "C:\deneme" -ot file -actn setowner -ownr "n:%USERNAME%" -actn ace -ace "n:%USERNAME%;p:full" -actn clear -clr "dacl,sacl" -actn rstchldrn -rst "dacl,sacl"
#3
Posted 03 June 2012 - 02:43 PM
Thanks for tip! But this feature is already available in the Leopard Project. I want to draw attention fact to the something else. Are we faced with such a problem without being aware for some commands in the Winbuilder ?
ShellExecute,Open,"%Tools%Leopard-%SysType%.exe","/SetAcL /TargetObject #$qc:deneme#$q"
Edit: A useful link for the subject.
http://www.howtogeek...-windows-vista/
#4
Posted 04 June 2012 - 05:20 PM
But for some reason, this problem is occurring with WinBuilder. Kind regards
#5
Posted 08 June 2012 - 08:46 PM
One thing I noticed - I couldn't delete files from my windows 8 installation using pe.
I had to use accessgain driver in pe to do it.
#6
Posted 10 June 2012 - 06:08 PM
I am not sure I fully understand the issue, but let me state what I think happened in the video...
You created a CMD window, and inside it created a directory.
Then you accessed the directory and it was all OK.
Now you changed the permissions on it, and it was blocked - again, this is OK.
Then you tried to take ownership, but still had issues in accessing the directory.
I think that as stated above this is all proper, But maybe the question needs more information given. We need to know more about the actual account you used to run winbuilder - were you actually logged in as "administrator" or with an account that has administrator privledges? Also, try executing the "whoami" command (i.e. tells you who the REAL account is, and not what type of access it has.
I believe that the use of "administrator" on the cmd window means access level, and not account name! This could be the cause of the confusion, since "Administrator" is both a level of access (actually Administrators) and account name...
But I am guessing that there is a question behind all of this - i.e. can we do things in winbuilder that can lead to trouble? I think the answer to that is yes...
But let us know!
Scott
- Max_Real Qnx likes this
#7
Posted 17 June 2012 - 09:53 PM
In fact, I didn't understand the reason of the problem. I am doing to the system login with administrative rights. So the WinBuilder working with Administrator rights. Error stems from the takeown.exe or the Winbuilder.exe . The takeown.exe very well working with autoit for Administrator rights.
RunAdmin.exe
#RequireAdmin ShellExecuteWait (@SystemDir & "cmd.exe", "", @SystemDir, "", @SW_SHOW)
But the takeown.exe gives the same error when this RunAdmin.exe is run with the Winbuilder.
[Process] ShellExecute,Open,"%UserProfile%DesktopRunAdmin.exe","","%UserProfile%Desktop"
Best regards
http://www.maxrealqn.../Why2/Why2.html
#8
Posted 17 June 2012 - 11:19 PM
Bets to you as well!
Scott
- Max_Real Qnx likes this
#9
Posted 18 June 2012 - 08:14 AM
Peter may be able to answer better, but my GUESS is that the internal way WinBuilder makes the actual system calls to the OS and the way that Autoit does it may be slightly different. They way MS manages the permissions and inheritance of them has always ben a mystery to me
Bets to you as well!
Scott
Hi sbaeder
Yes, but a programmer can solve this problem. I agree with you. So I think, one of expert in both the AutoIt and Delphi programming languages better understand what source of the problem. In fact, my point I want to draw attention; without being aware of this same problem are we encountering in other programs ? Otherwise, if this is a simple takeown.exe bug, does not create a problem for me (we?). Kind regards
#10
Posted 19 June 2012 - 09:18 AM
To obtain rights please use the command:
icacls "C:\deveme" /Reset
- Max_Real Qnx likes this
#11
Posted 19 June 2012 - 09:53 AM
Wow! Yes, the problem can be solved in this way. Thank you for your valuable support. However, the takeown.exe file's error is still not solved. No longer I leave it to the reason of problem to programmers. Kind regards
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users