Jump to content
Sign in to follow this  
Au3Builder

DirCopy and DirMove functions are broken when run with elevated permissions

Recommended Posts

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).thumb_Network_Folder-2.png

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 by Au3Builder

Share this post


Link to post
Share on other sites
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: .

 

Share this post


Link to post
Share on other sites
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 by Au3Builder

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Earthshine

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

  • Like 1

My resources are limited. You must ask the right questions

 

Share this post


Link to post
Share on other sites
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 by jdelaney
  • Like 4

IEbyXPATH-Grab IE DOM objects by XPATH IEscriptRecord-Makings of an IE script recorder ExcelFromXML-Create Excel docs without excel installed GetAllWindowControls-Output all control data on a given window.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×