Archive: CopyFiles problem with Windows 2008 Server


CopyFiles problem with Windows 2008 Server
  I have a script that worked fine for Windows 2000 and Windows XP and 2003 Server, I haven't tested it on vista, but on 2008 Server the CopyFiles command is always failing.

this is my script:

  ClearErrors

CopyFiles "$INSTDIR\\Server\\myLib.dll" "$INSTDIR\\Server\\myLib-w.dll"
IfErrors 0 +2
Abort "Error copying Server Library"
And it always fall in the IfErrors clause


Any ideas on what to do?

Check if the file even exists in the first place. And check if you have sufficient access privileges to write to that subdir. The directory might also need to exist before you start copying.


The directory exists, and i'm running the installer as administrator (the original file was created with another installer which as run as the administrator as well), if I run these commands:

  Rename    "$INSTDIR\Server\myLib.pdb" "$INSTDIR\Server\myLib-w.pdb"

IfErrors 0 +2
Abort "Error copying DLL's PDB"
ClearErrors
File "files\myLib-wrapper.dll" "$INSTDIR\Server\myLib.dll"
IfErrors 0 +2
Abort "Error installing wrapper"
then it runs OK...

I'm noticing a distinct lack of backslashes in that code... o__O


The first one i've reviewed and scaped the backslashes, this one I didn't notice before it was too late (I can't edit it anymore). But the backslashes are there...


You possibly have the installer set to not overwrite existing files?
http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.2.8


The destination file does not exist (but the origin file exists, as well as the destination folder)

Anyway, the overwrite was set with

  SetOverwrite try 

in a previous (not optional) section.

Is there any register with the error cause? Or any other ideas?

Eh? If the file doesn't already exist, why does renaming the existing file have any influence?


It doesn't, I just said that renaming works to demonstrate that I have permissions on the folder.

I'm curious to know why it worked fine on XP, 2K and 2003 Server and doesn't work on 2008 Server...

CopyFiles uses a superseeded Windows API, but I don't think that's the reason...

When it fails it just log that's failed, it doesn't log why...


I suppose you could dive into the code, see which API call is made for CopyFiles, and then call it yourself using the system plugin. You might just be able to get a more detailed returncode from that.