The testprogram CopyFiles.exe should copy all contents from the 
backupdir 'SPBackup' up one level to the directory where 
'CopyFiles.exe' resides. 

The installercode is actually a part of a servicepack which includes 
a built-in undo-function to restore files which are backupped in a 
subfolder of my application prior to execution of the servicepack.

I use CopyFiles because I don't know how much files and folders there 
will be in SPBackup's subfolders in the future. The test only assures 
that the subfolders are not empty and contain some core-files.

It would be nice when I do not have to care about a cleanup before 
copying the files, which means CopyFiles should support errorfree 
replacement of existing (unlocked and r/w) files and directories.

Some tests have shown, that there are even problems with long filenames. 
The dirs Go, noGo and Swap show 3 scenarios; all files are identical, 
except for the filenames in the lang-subdir of SPBackup:

The scenario in 'Go' has files with long filenames and only one fileextension 
(one dot) in the subdir 'SPBackup\Lang'. Starting CopyFiles.exe for the first 
time will be fine, although the filenames in the destinationdir 'Go\Lang' are 
truncated after the first 8 chars. The extension, however, remains untouched !   
Starting the program a second time, reveals that there was an error regarding 
the files in Go\Lang: they could not be replaced by the backup in Go\SPBackup\Lang. 
Merely deleting 'Go\Lang' and starting the exe once more, proofs that files can 
be replaced by CopyFiles without errors. If replacement of existing files 
would not be possible there would have been an error replacing e.g. the 'Images' 
directory. 

The scenario in 'NoGo' exhibits the error of my first post: the filenames in 'Lang'
have 2 dots and are identical up to the first dot.
Starting the exe will show an error already at the first try and the filename in the
destination is missing the part between the two dots, which makes both filenames 
identical and is - as I guess - the problem, which finally set the errorflag.

In the scenario 'Swap' I swapped the parts of the filenames of 'NoGo\SPBackup\Lang' 
so that there should not be the problem of identical filenames when removing some 
part of the filename. The results are similar to the scenario 'Go': first try, 
no errors, but truncated filenames; truncation begins at the first dot, extension 
remains untouched. The 2nd try will give an error.

Note, that in all three examples - regardless of the errorflag - something is done 
with the filenames in the destination directories - this cannot be OK...

Copying and pasting in the explorer works perfect and like expected, so I believe 
there must be missing some switch when NSIS calls the shellfunction to copy the 
files. I guess it has something to do with 8.3.-compatibility, although the 
resulting filenames are truncated and not converted to something containing a 
'~', as one would expect. Maybe there is an environment or system variable, which 
is able to correct this behavior of copyfiles ?

My system is WinXP Pro, SP1, German, no patches. Testing was done in the root of 
a local NTFS partition and in a subdirectory of a network-share on a linux partition.
Identical results on both drives.

Are you able to reproduce the results on the same or a different platform ?

In the meantime I will try reproduce kichik's example, which is slightly different: 
he copies the files to a deeper directory level, which I will need for the 
backup-function of my servicepack... Another test will be to choose an absolute 
path for ${SRCDIR}. Here it is a '!define "."'. In the final version this will 
be a register and its value will be set at runtime and thus could contain an 
absolute path.

