Bug in CopyFiles - NSIS Forums

niteflyer
3rd February 2005 18:02 UTC

Bug in CopyFiles
I have found a bug in CopyFiles, which I can reproduce with NSIS 2.0 and NSIS 2.04 (makensis.exe from makensis204_log.zip): obviously, this command does not properly handle filenames with more than one extension ('filename.ext.ext').

I want to copy two files 'lang.german.gmt' and 'lang.english.gmt' with

CopyFiles /SILENT "${DSTDIR}\SPBackup\*.*" "${DSTDIR}"

After this, the Errorflag is set and one file (probably the one, which was copied at first) got the name 'lang.gmt'.

The other one was not copied. Apparently the command stopped after this, because there were several 'normal' files in other subdirectories, which should have been copied by this statemant too.

This is not a problem with long filenames because it works with 'langgerman.gmt' and 'langenglish.gmt' !

I am using WinXP/SP1.

kichik
3rd February 2005 19:16 UTC

CopyFiles simply calls the shell copying function. It's the same as using Explorer to do that copy operation. Does it work for you with Explorer?

niteflyer
3rd February 2005 19:34 UTC

It does work with the explorer.

And CopyFiles works just as expected when _not_ using multiple extensions: it copies the contents of the folder (including all subfolders, although somebody affirmed something else (joost?), when a /r-option was requested in another thread). CopyFiles even replaces existing files/folders without Errorflag, which is exactly what I need.

Some idea ?

kichik
3rd February 2005 19:59 UTC

The following code works fine for me:

CreateDirectory $TEMP\copyfilestest\2
FileOpen $0 $TEMP\copyfilestest\lang.english.gmt w
FileClose $0
FileOpen $0 $TEMP\copyfilestest\lang.german.gmt w
FileClose $0
CopyFiles $TEMP\copyfilestest\*.* $TEMP\copyfilestest\2

What exactly do you mean by multiple extensions? I don't see anything in your example related to that.

Afrow UK
3rd February 2005 20:34 UTC

I think he means that it has more than one dot in it.

-Stu

kichik
3rd February 2005 20:37 UTC

Indeed, but the CopyFiles instruction in the first post simply uses *.*, and that works, as shown in my example.

Afrow UK
3rd February 2005 21:03 UTC

Could you make an cut-down example script which reproduces this error?
I can't get the error to occur using the code you attached in the first post.

-Stu

niteflyer
4th February 2005 12:58 UTC

example
here is an example. I hope it helps...

kichik
4th February 2005 13:20 UTC

All of the examples work completely fine for me. There are no errors and the results are as expected. MSDN doesn't describe any SHFileOperation flags related to truncating file names. The difference between Explorer and CopyFiles might be the usage of *.* in CopyFiles. Try copying file by file with CopyFiles and see if it happens.

This shell behavior might be caused by a malfunctioning shell extension. Try removing any shell extensions you've installed lately. I'd also run some anti adware/spyware software to make sure it's not caused by that.

niteflyer
4th February 2005 15:13 UTC

@kichik:

Did you check the filenames in the 'Lang' directories ?

here is my dir *.gmt /s:

Verzeichnis von D:\CopyFiles\Go\Lang

04.02.2005 11:17 9 langengl.gmt
04.02.2005 11:17 8 langgerm.gmt
2 Datei(en) 17 Bytes

Verzeichnis von D:\CopyFiles\Go\SPBackup\Lang

04.02.2005 11:17 9 langenglish.gmt
04.02.2005 11:17 8 langgerman.gmt
2 Datei(en) 17 Bytes

Verzeichnis von D:\CopyFiles\noGo\Lang

04.02.2005 11:17 9 lang.gmt
1 Datei(en) 9 Bytes

Verzeichnis von D:\CopyFiles\noGo\SPBackup\Lang

04.02.2005 11:17 9 lang.english.gmt
04.02.2005 11:17 8 lang.german.gmt
2 Datei(en) 17 Bytes

Verzeichnis von D:\CopyFiles\Swap\Lang

04.02.2005 11:17 9 english.gmt
04.02.2005 11:17 8 german.gmt
2 Datei(en) 17 Bytes

Verzeichnis von D:\CopyFiles\Swap\SPBackup\Lang

04.02.2005 11:17 9 english.lang.gmt
04.02.2005 11:17 8 german.lang.gmt
2 Datei(en) 17 Bytes

I get the same results without virusscanner, firewall, database and other background tools.

The results are similar with W2k, SP4, English. The difference here is that for 'noGo' both files could be copied as lang.gmt and lang1.gmt.

A test on a NT4-VM gave errors for all 3 cases: not a single file could be copied.

kichik
4th February 2005 15:20 UTC

Works fine with XP, but it started making up weird names with 98. I'll take a look later, after 2.05 is completely released.

niteflyer
4th February 2005 15:46 UTC

@kichik: Thanks.

Anybody else, who can confirm my problem on nt/2k/xp-machines ?

By the way, I've found a workaround for the problem:

Everything will work fine, when using absolute paths for ${SRCDIR}.

Thus, if you change

!define SRCDIR . ; same dir like copyfile.exe

to

!define SRCDIR d:\copyfiles\go
OR
!define SRCDIR d:\copyfiles\nogo
OR
!define SRCDIR d:\copyfiles\swap

in the 3 scripts, there will be no errors (tested with XP). It helps me, because this was my first idea to set the SrcDir at runtime. Using '.' was only a quick solution, for testing this piece of code.

kichik
4th February 2005 16:34 UTC

Right, probably has something to do with:

You should use fully-qualified path names with this function. Using it with relative path names is not thread-safe.

I do not know how it gets from non-fully-qualified path names to weird name changes, but I see nothing else about it in MSDN. I'll add a warning to the documentation.

[EDIT]

There's also:

These names must be fully qualified paths.

and

Use only fully-qualified paths. Using relative paths will have unpredictable results.

niteflyer
4th February 2005 17:21 UTC

!define SRCDIR $EXEDIR ; same dir like copyfile.exe

is better for the demoscript, if $EXEDIR is guaranteed to be fully-qualified. And I should have used DSTDIR instead of SRCDIR, that's a bit irritating. With this change the script works for all 3 examples.

Have a nice weekend...