jhop
23rd April 2013 17:02 UTC

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                
                ClearErrors
                Delete "$INSTDIR\My.cfg"
                ${If} ${Errors}
                        !insertmacro Log 2 "ERROR: Can't delete $INSTDIR\My.cfg" 
                        ClearErrors
                ${Else}                 
                        !insertmacro Log 3 "Deleted $INSTDIR\My.cfg" 
                ${EndIf}
                                
                ClearErrors                                     
                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" '                    
                ${EndIf}

Afrow UK
23rd April 2013 18:45 UTC

Have you tried using $PLUGINSDIR instead?

Stu

Anders
24th April 2013 01:20 UTC

Copyfiles uses SHFileOperation internally, it is not listed on http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx not sure if that means it is not going to work...

jhop
24th April 2013 09:18 UTC

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.

Anders
24th April 2013 09:57 UTC

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

jhop
24th April 2013 12:16 UTC

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.

Anders
25th April 2013 04:30 UTC

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

Afrow UK
25th April 2013 13:13 UTC

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.

Stu

bnicer
25th April 2013 17:52 UTC

Hi,
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.

bnicer
25th April 2013 23:13 UTC

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:

10881542

Copy to add000.htm

7866318

Copy to add001.htm

4720712

Copy to add002.htm

3409852

Copy to add003.htm

8062710

Copy to add004.htm

7080108

Copy to add005.htm

10881116

Copy to add006.htm

10750470

Copy to add007.htm

0

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.

Anders
26th April 2013 05:32 UTC

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

bnicer
26th April 2013 10:17 UTC

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.

Anders
26th April 2013 12:24 UTC

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