Archive: FileCopy Fail on Windows ServerCore

FileCopy Fail on Windows ServerCore
  Hi, I am making an installer with NSIS.

I have come across a strange behaviour on Windows ServerCore

What I am doing is in an upgrade situation, I am copying the existing configuration files to the $TEMP directory. Then I do an install of the new files. After that I copy the configuration from $TEMP back into InstDir.

This works fine on Windows7, but on ServerCore I am getting file copy errors.

To try to get some error message back from the Copy, I used cmd to copy the files, and then, that worked! So using the DOS copy command works, but CopyFiles doesnt.

Any Ideas why?

;Restore the pre-existing settings files                
Delete "$INSTDIR\My.cfg"
${If} ${Errors}
!insertmacro Log 2 "ERROR: Can't delete $INSTDIR\My.cfg"
!insertmacro Log 3 "Deleted $INSTDIR\My.cfg"

CopyFiles "$TEMP\My.cfg" "$INSTDIR\My.cfg"

${If} ${Errors}
!insertmacro Log 2 "ERROR: Copy Files $TEMP\My.cfg $INSTDIR\My.cfg"
Exec 'cmd /K copy "$TEMP\My.cfg" "$INSTDIR\My.cfg" '

Have you tried using $PLUGINSDIR instead?


Copyfiles uses SHFileOperation internally, it is not listed on not sure if that means it is not going to work...

CopyFiles is 'core' NSIS functionality? Can I get a definitive answer if it is expected to work?

I guess I can us my DOS hack to get by, but I'd rather use proper functions.

SHFileOperation has been a part of Windows since Windows95 which is why NSIS uses it as the workhorse of the CopyFiles instruction. What MS defines as core 15 years later is not really under our control...

You could call the low level version with: System::Call 'kernel32::CopyFile(t "c:\file.ext", t "c:\newfile.ext", i 0)i.r0' and $0 will be 0 on errors

that kernel32::CopyFile works. Thanks a million.

No idea why, I use a lot of CopyFile calls, and most work, except those two. They are copying into ProgramFiles, that might be linked...though I installed into C:\<MyFolder> and had the same issue.

but...its working.

Thanks again for the prompt replies.

If some of the CopyFile calls work they should all work, this sounds very weird...

Could it be a CopyFiles popup that is causing the copy to fail (i.e. try using /silent)? I guess you could try with a large file to find out.


Hope I'm not butting in ...

You can ignore this.

It occurs to me that to disable the log text "Copy to:" and "Copy failed" when you use CopyFiles, 'kernel32::CopyFile' is a solution. Pop $0 to see if copying succeeded or failed and insert custom log text. You don't have to resort to SetDetailsPrint none.

Just an obversation I'd make. I don't know what's causing CopyFiles to not work.

Speaking of weird -- I'm copying a group of small files, some of which are locked.

System::Call 'kernel32::CopyFile(t "$PLUGINSDIR\${folder}\${file}", t "$OUTDIR\${file}", i 0)i.r0'
Pop $0
DetailPrint $0

The log output gives me something entirely weird:


Copy to add000
Copy to add001.htm
Copy to add002.htm
Copy to add003.htm
Copy to add004.htm
Copy to add005.htm
Copy to add006.htm
Copy to add007.htm
Copy failed: add008.htm
All of the files are locked and the exit code for each should be zero. I can swap any nine locked files. The result is consistently that it takes until the nineth one before the Pop $0 returns 0. None of the files do get copied, because they're all locked. Once the nineth file has been passed, the copying behavior is correct. Pop $0 returns 0 or 1, depending on whether the file is locked or not.

Luckily CopyFiles does work. I'm on Windows 7. I think you may have to Push and Exch in order to fix 'kernel32::CopyFile'. I'm too lazy to give it a go.

Who told you to pop? If you want to pop then the system code should end with ...)i.s'

Yes, it works perfectly. Thanks. Without Pop. :o

It seems a lot faster than CopyFiles. I use the error code to pop up a message. A lot faster with many messages.

Is there no drawback, like that it would not run silently, when you copy large files? I know it probably does run silently, but if there's the slightest chance of a window popping up, ...

Thank you very much indeed, Anders.

CopyFiles uses the same copy engine as Explorer, kernel32::CopyFile is a much more low level copy and should never display anything when called from NSIS