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.

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)?

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.

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

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.

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.

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.

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

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

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

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

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?

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

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.

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

Well? Has anyone tried KB931770?

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).

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

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:😁estroyWindow(i R1)`

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.

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).

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.

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 😉

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?

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"