10 replies to this topic

[Max_Real Qnx]

Hi my friends

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

[u2o]

Hi!

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"

[Max_Real Qnx]

Hi u2o

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/

[Max_Real Qnx]

Yes, please someone tell me about this subject I was wrong. Because when I make run the command prompt with runas administrator feature at the windows7, such a problem isn't formed.
But for some reason, this problem is occurring with WinBuilder. Kind regards

[SIW2]

I don't know why you are getting that Max.

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.

[sbaeder]

Max,

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]

Hi sbaeder

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

[sbaeder]

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

[Max_Real Qnx]

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

[u2o]

Max, please you understand this, you are the owner of the file (or administrators group) does not mean that you have granted rights. You take away the rights to the group: administrators, and although used takeown (and the folder is already owned), that does not change the denial of editing the rights on that folder.

To obtain rights please use the command:

icacls "C:\deveme" /Reset

[Max_Real Qnx]

Hi u2o

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