Vista problem using CopyFiles

KrisAster
15th August 2007 14:11 UTC

Vista problem using CopyFiles
I have an install that uses CopyFiles to copy some larger files. Because it is not in silent mode (nor do I want it to be), a progress dialog opens. But, when being run on Vista this progress dialog does not close when the files have finished copying.

I made a simple installer just to test the problem, which looks something like:

CopyFiles "temp.txt" "temp2.txt" ; temp.txt being 10 MBs

The progress dialog becomes a dead window after it's finished. It will still allow the user to interact with the windows underneath, and when the finish button is pressed and the installer is closed the progress dialog will disappear. Obviously, though, this behavior is not desireable.

Has anyone else had this problem and is there a workaround?

Thank you.

Backland
15th August 2007 14:53 UTC

If you set the /SILENT flag for CopyFiles, it will only supress that progress dialog, it will not make your installer a silent one, if thats what you mean.

Obviously this is only a workaround and there will be no progress report at all. Does the problem also occur with smaller files (<1MB)?

KrisAster
15th August 2007 16:11 UTC

No, this problem does not occur on files < 1MB because the dialog does not show up.

I've contemplated using the /SILENT mode as a workaround, but when copying 300MBs or more it could seem as if the installation hung.

demiller9
15th August 2007 16:51 UTC

I don't have personal experience with Vista, but I've read that file copies sometimes don't finish for a very long time. The file copy progress dialog is generated by the API called to do the copy. If it doesn't close at the end, that sounds like a Vista issue and not an NSIS issue.

Don

KrisAster
15th August 2007 18:45 UTC

I think you're probably right demiller9. It does seem to be at minimum a change in the way that Microsoft handles its copy dialog.

I DO know that the copy is finished by the time it moves on. The progress dialog (behind the poped up dialog) will show the rest of the installation continuing as it should. When finished is pressed, the offending dialog is removed.

Backland
15th August 2007 19:00 UTC

I'm guessing a look at the NSIS source which calls that particular shell function might reveal more.

If someone with Vista could also try to replicate the issue, it could also tell us if its a Vista or NSIS problem, or an issue that is specific to your script.

KrisAster
15th August 2007 19:19 UTC

Here is a copy of the .NSI file I used to duplicate the problem. As you may be able to see, there is nothing special about it. It has the code that I had mentioned earlier was able to duplicate the problem.

All it really does is copy TEMP.TXT to TEMP2.TXT in the directory of the Setup.exe. TEMP.TXT needs to be of a substantial size to open up that dialog.

KrisAster
15th August 2007 19:21 UTC

I suppose it *might* help if I attached the script.

kichik
15th August 2007 21:37 UTC

You should always use full paths with CopyFiles. That might not solve the problem but should prevent others.

KrisAster
16th August 2007 15:13 UTC

Thanks for the tip. This was just a dummy test script. In my release script full paths are used.

thegrinch
18th August 2007 12:46 UTC

Hi!

I am just sitting here being confronted with exactly the same problem:

My installer copies a larber amount of files and the status dialog does not disappear as it should after being finished.

As soon as the user confirms with the "Finish" button the installer, both the installer as well as the CopyFiles status dialog close.

I did not use the /SILENT option.

Is this behaviour a known bug? Or, since the installer was compiled some weeks ago, has this bug perhaps already been solved ???

Thank you for your gread support and help in advance!

Best regards!

thegrinch

kichik
18th August 2007 12:53 UTC

It's not a known bug of NSIS, but I wouldn't be surprised to find out it's a known bug of Vista which will be fixed in SP1. Have you tried this with the SP1 beta?

thegrinch
18th August 2007 13:17 UTC

No, I hav not tried this.

To be honest, today is the first time for me to really test and try my installers under Vista. Up to now I tried to "get around" the - sorry for saying so - mess of Vista. As far as I knew, Service Packs just consist of a collection of updates. So, if one installs all updates, there should not be a difference to installing the Service Pack. Am I right?

Again, thank you very much for your great and fast answers!

regards

thegrinch

kichik
18th August 2007 13:33 UTC

Originally posted by thegrinch
As far as I knew, Service Packs just consist of a collection of updates. So, if one installs all updates, there should not be a difference to installing the Service Pack. Am I right?

No. Take XP SP2 as an example. It had lots of functionality changes not available as separate updates. Vista SP1 should also have some of those like their latest "improved performance pack" which also speaks about file copy performance.

demiller9
18th August 2007 23:24 UTC

Microsoft has article KB931770 on Vista copy problems "The copy process may stop responding..." and a lengthy discussion is here "calculating time remaining moving,deleting,copying files very slow"

The people who posted in the forum (second link) claim the hotfix in the first link also worked on copies made on their local drives, not just to the network like the hotfix mentions.

Don

kichik
1st September 2007 08:21 UTC

Well? Has anyone tried KB931770?

BrianWeed
21st September 2007 15:54 UTC

I am also having this problem....CopyFiles dialog does not close on Vista.

Is there an alternative to CopyFiles (that will copy files with a progress bar, not from the embedded archive).

kichik
21st September 2007 16:01 UTC

You can run CopyFiles silently with the /SILENT flag, but you should try KB931770 first.

BrianWeed
29th August 2008 23:56 UTC

Adding the following code after the CopyFiles instruction also seems to workaround the problem (in some cases):

System::Call `kernel32::GetModuleHandle(i 0) i.R3`
System::Call `user32::CreateWindowEx(i 0, t "STATIC", t "", i ${WS_CHILD}|${WS_VISIBLE}, i 0, i 0, i 100, i 100, i $HWNDPARENT, i 0, i R3, i 0) i.R1`

Sleep 900

System::Call `user32::DestroyWindow(i R1)`

stb
31st August 2008 20:08 UTC

I cannot recommend using CopyFiles for installers. It has several problematic side effects (e.g. copying meta data of files). You generally do not want those effects.

BrianWeed
2nd September 2008 15:49 UTC

We also found that calling MessageBox after CopyFiles will prevent the problem (causes the CopyFiles dialog box to go away when the MessageBox dialog comes up).

Johnm312
12th September 2008 01:03 UTC

One of my main installers is biased on NSIS and the ability to copy files and with additional scripting option the hunt and pick through hundred of folders with 1000's of files in My add-on packs to install the exact game packs my users wants for their game play environment. This bug is becoming a bit of a pain in that arse for me.

I am sure it is a vista thing. It usually only does it on the first pass, after that it is fine until I let it sit for a while. then it starts all over with the 0MB found 0Seconds remaining.

bgutman
4th March 2009 08:56 UTC

I've found a workaround for this bug. It's not pretty, but seems to work.

It is based on the observation that "Copy Files" dialog is a top-level window belonging to the same process as the setup. Thus, we enumerate top-level windows, looking for one from the same process whose handle is different from HWNDPARENT. When found, we kill its thread with TerminateThread(). I know this is brutal and not recommended, but there seems to be no other way. Sending a WM_CLOSE message to this window changes dialog's title to "Canceling..." , but does not close it.


Function VistaCopyFilesWorkaround
        ;get PID into $R1
        System::Call "kernel32::GetCurrentProcessId() i.R1"
        ;define callback for EnumWindows
        System::Get "(i.r1, i) iss"
        Pop $R0
        System::Call "user32::EnumWindows(k R0, i) i.s"
        loop:
                Pop $0
                StrCmp $0 "callback1" 0 done
                System::Call "user32::GetWindowThreadProcessId(i r1, *i .r2) i.r3"
                ;hwnd=$1, process ID=$2, thread ID=$3
                StrCpy $0 "1" ; callback's return value (1=continue enumeration)
                IntCmp $2 $R1 0 onceagain onceagain
                        ;same process, check HWND
                        IntCmp $HWNDPARENT $1 onceagain 0 0
                        ;different HWND found, try to close
                        System::Call "kernel32::OpenThread(i 1, i 0, i $3) i.r4"
                        System::Call "kernel32::TerminateThread(i $4, i 0)"
                        StrCpy $0 "0" ; callback's return value (0=break enumeration)
                onceagain:
                Push $0
                System::Call "$R0"
                Goto loop
        done:
        System::Free $R0
FunctionEnd

Call this function after CopyFiles.
Hope this helps someone ;)

Collector9999
9th March 2009 00:41 UTC

I tried this function, but it did not work. Could it be because I have Vista 64? My installers copy large files from existing CDs. I don't want to suppress all of the progress dialog. Is there anyway to just suppress the copy popup?

bgutman
12th March 2009 09:13 UTC

Could it be because I have Vista 64?

Maybe, I only tested on Vista 32.

Is there anyway to just suppress the copy popup?

Yes, use "CopyFiles /SILENT"