DirCopy and DirMove functions are broken when run with elevated permissions

[Au3Builder]

To begin with I'm still using v3.3.14.2 because the newest release is bugged. 

I have another computer on the network on which I created a shared network folder looking like this (available for everybody).

i execute the script below on a standard user account. UAC asks me for admin password so i enter the password,then  msgbox returns 0 (error in other words). nothing is copied.

#RequireAdmin
$result = DirCopy("\\192.168.1.20\Logs","Backup",1) ; All Users have full-access to the "Backup" folder.

msgbox(0,'',$result) ; Fail

To my amazement,AutoIt script copies all files,folders and sub-folders from network location to "backup" but only after removing #RequireAdmin from the script.

$result = DirCopy("\\192.168.1.20\Logs","Backup",1)  ;All Users have full-access to the "Backup" folder.

msgbox(0,'',$result) ; Success

 

The problem is I need to copy logs to C:\Program Files\... willy-nilly I must have admin rights to access or modify this catalog.

 

my question is it an internal autoit bug or do i do anything wrong?

 

 

 

Edited February 8, 2018 by Au3Builder

[t0nZ]

Hi @Au3Builder, so you have already checked and with the "old" autoit release the copy is working well ?

In your code, do you use \\192.168.1.20 (the ip address) or maybe a network drive letter ?

Because if you attach the network drive X: for \\192.168.1.20\logs, maybe you have connected  it only to your standard user, and the other user (like admin) can not see the shared drive X: .

 

[Au3Builder]

37 minutes ago, t0nZ said:

Hi @Au3Builder, so you have already checked and with the "old" autoit release the copy is working well ?

In your code, do you use \\192.168.1.20 (the ip address) or maybe a network drive letter ?

Because if you attach the network drive X: for \\192.168.1.20\logs, maybe you have connected  it only to your standard user, and the other user (like admin) can not see the shared drive X: .

 

No I haven't checked old releases.DirCopy get the contents via network location without mapping the drive. both computers are connected to the domain. seems that my script run as local or domain admin cannot get anything from the share.CopyDir returns some number in @extended macro but I don't know where I can check forit's meaning,Is it possible that standard user can do something more that admin can't?

Edited February 8, 2018 by Au3Builder

[t0nZ]

Very strange indeed, I was upgrading my autoit but I'am waiting for this topic, I'am in a domain too so when I have time and if nobody else reply I set up a test in another machine.

Bye

[Earthshine]

I tested your code with admin. works great on a UNC drive/path.... hmmmm permissions issues for you

[jdelaney]

Run the script with #requireadmin so you have access to your local directories.  When running as admin, do a DriveMapAdd as the shares admin user.

Now you are admin in scope locally, and on your share, and the copy should be just fine using the drive letter you set.

After mapping the drive, you can open it in an explorer window via your script, and verify you do in fact have access to the directory you are attempting to copy.

Explained: when you are running as your local|domain user that you login as, you already have access to the drive without the mapping.  When you are running as admin, you are NOT running as your local|domain user, and your local admin does NOT have access to the share, nor any mapped drives.  So you can run without #requireadmin, and copy to a folder that doesn't require local administrator rights (not protected folders), or run as admin, and map the drive.  This is a windows security thing, and not an autoit 'bug'.  And just to say this in general...if you think something IS a bug, I'd bet it's actually a user error :).

Edited February 8, 2018 by jdelaney

[Au3Builder]

10 minutes ago, jdelaney said:

Run the script with #requireadmin so you have access to your local directories.  When running as admin, do a DriveMapAdd as the shares admin user.

Now you are admin in scope locally, and on your share, and the copy should be just fine using the drive letter you set.

After mapping the drive, you can open it in an explorer window via your script, and verify you do in fact have access to the directory you are attempting to copy.

Explained: when you are running as your local user that you login as, you already have access to the drive without the mapping.  When you are running as admin, you are NOT running as your local user, and your local admin does NOT have access to the share, nor any mapped drives.  So you can run without #requireadmin, and copy to a folder that doesn't require local administrator rights (not protected folders), or run as admin, and map the drive.  This is a windows security thing, and not an autoit 'bug'.  And just to say this in general...if you think something IS a bug, I'd bet it's actually a user error :).

Your answered my question perfectly. Thanks.