mgillespie
21st July 2003 18:17 UTC

NT4 CopyFiles - Return value not working.
Have posted a bug on the SF tracker (not sure if anyone looks there, so posting here also).

I have a project that uses the CopyFiles function. I check the error value after copying to ensure the file was copied correctly.

This works fine under Win2k, but fails under NT4 (SP6a), where it always reports a good copy, even if it can't find the source file.

Sample Code to reproduce the problem:

!include "MUI.nsh"
!define MUI_PRODUCT "Modern UI Test"
!define MUI_VERSION "1.65"
OutFile "Basic.exe"

!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_LANGUAGE "English"

Section "modern.exe" SecCopyUI
ClearErrors
CopyFiles "C:\1.txt" "D:\"
IfErrors +1 +3
MessageBox MB_OK|MB_ICONSTOP|MB_TOPMOST "Copy Failed"
Goto +2
MessageBox MB_OK|MB_ICONSTOP|MB_TOPMOST "Copy OK"
SectionEnd

Complile this, and ensure that C:\1.txt does not exist. On Win2k, it will flag a error on CopyFiles, NT4 will report it as OK.

mgillespie
21st July 2003 19:31 UTC

Has anyone reproduced this problem? Or is it me????

mgillespie
21st July 2003 21:10 UTC

the problems with return values from SHFileOperation under NT4 seem to be widely reported on Google, but nothing I can see on MSDN.

Is there any reason SHFileOperation is used over the more usual CopyFile() functions from the FileStorage PlatformSDK?

This seems to work correctly on NT4:

case EW_COPYFILES: // CopyFile (added by NOP)
{
int res;
char *buf0=process_string_fromparm_tobuf(0x00);
char *buf1=process_string_fromparm_tobuf(0x11);
log_printf3("CopyFiles \"%s\"->\"%s\"",buf0,buf1);
buf0[mystrlen(buf0)+1]=0;
buf1[mystrlen(buf1)+1]=0;

wsprintf(buf2,"%s%s",LANG_STR(LANG_COPYTO),buf1);
res = !CopyFile( buf0, buf1, TRUE );
if (res)
{ // some of these changes were from Edgewise (wiked_edge@yahoo.com)
update_status_text_from_lang(LANG_COPYFAILED,"");
g_flags.exec_error++;
}

Afrow UK
21st July 2003 21:30 UTC

This was a bug and was actually fixed early today by Kichik.
Please download the latest CVS.

-Stu

kichik
22nd July 2003 08:28 UTC

I wish that was true Afrow, but unfortunately I don't have access to Microsoft code yet :) As mgillespie said, it's a bug with SHFileOperation under NT 4 SP6.

CopyFile is not used because, at least according to MSDN, it does not support wild cards. We might end up writing our own NSFileOperation because this function only brings problems. For now, you'll have to avoid this bug using either methods you've already presented above.

Afrow UK
22nd July 2003 16:53 UTC

LOL my mistake :)

The best way would be to:

CopyFiles "sourcefile" "copiedfile"
IfFileExists "copiedfile" 0 +3

-Stu

mgillespie
22nd July 2003 20:48 UTC

That would cover 1 aspect of the problem, but there are many other problems that could case a file copy to fail, but would not get trapped.

I am using tweaked Installer source anyhow, so I may just change the EW_COPYFILES case to use CopyFile (until something happens in the mainstream code to fix this).

It does seem this particular script function is troublesome, as it also causes compile problems on VS6 without the latest Platform SDK. Writing a dedicated CopyFile with wildcards function would solve this also.

If someone could supply a quick spec for a wildcard FileCopy, I can do some code for it (if required), and submit it.

kichik
23rd July 2003 13:02 UTC

To supply wild card support you can copy the code from EW_DELETEFILE. If you're already on it, why not add RMDir support too and make it a complete replacement for EW_DELETEFILE, EW_RMDIR, EW_RENAME and EW_COPYFILES?