PKDucky Posted July 15, 2014 Author Posted July 15, 2014 I think I found the issue. I did a simple test and renamed the file to 1.jpg and put it in C:Temp. The script consists of the following #RequireAdmin FileCopy ("C:Temp1.jpg", "C:"FileCopy ("C:Temp1.jpg", "C:Windows" FileCopy ("C:Temp1.jpg", "C:\Windows\System32\" FileCopy ("C:Temp1.jpg", "C:\Windows\System32\oobe" FileCopy ("C:Temp1.jpg", "C:\Windows\System32\oobeInfo" FileCopy ("C:Temp1.jpg", "C:\Windows\System32\oobeInfoBackgrounds" Running the script, the file gets copied to 'C:' & 'C:Windows' and no further. Its Windows 7 Enterprise SP1. I am thinking Windows has some built in protection. Gordon, for your sample script, the first one did nothing, the second did briefly delete the Backgrounds folder.
GordonFreeman Posted July 15, 2014 Posted July 15, 2014 (edited) No makes sense, must be one line to copy one file. Anyway it looks a protected/special folder of Windows. But i will try help more when i back to home. Edit: But i not know why you need copy in this path instead of other. In my installation not have a "info" folder in oobe Win7 Home Premium 32 Edited July 16, 2014 by GordonFreeman Frabjous Installation
lorenkinzel Posted July 18, 2014 Posted July 18, 2014 I ran into the same issues as you did using the simple test in post 21. It appears to be a redirection, perhaps used as protection. I worked around it with (gleaned from others): $command = ("xcopy ") ; I have the quotes seperated because I would normally use a variable instead of:'C:\Temp\1.jpg'. Spacing around quotes is unforgiving with xcopy. $source = ('"' & @DesktopDir & '\countSec.au3' & '" ') $dest = ('"' & 'C:\Windows\System32\oobe\Info\Backgrounds\' & '"') DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1);this one does it RunWait(@ComSpec & " /C" & ' ' & $command & $source & $dest);, $switches) I only used xcopy because I, in error, felt that would be the workaround. That & it has such a cool name.... The real workaround was the dllCall. FileCopy will probably / possibly work here. I did'nt try fileCopy once this one worked. Incidentally, the "others" that I gleaned this info from expressed strong opinions that we ought not copy things into system32.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now