Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Problem with CopyFile


6 replies to this topic

gkcom123

gkcom123
  • Members
  • 4 posts

Posted 13 September 2006 - 04:43

Hi

I am using BASIC MSI project in which i m installing a file(xxx.config) in [TempFolder]

Installation of file is happening in TempFolder but when i m using the function
like this

nResult = CopyFile(TempFolder^\\xxx.config,TARGETDIR^\\xxx.config)

NResult value is -2147024894 (An unspecified error occured)

I checked , file is present in temp folder.
But In copyFile function it is referring to some other place.

File is in "C:\Doc&Set\user\localsetting\Temp\2"
but in Copy file function TempFolder is "C:\Doc&Set\user\localsetting\Temp"

How to get a workaround on this.

Thanks





woter324

woter324
  • Full Members
  • 18 posts

Posted 27 May 2007 - 21:16

Hi,

I have the same problem. Did you find a resolution to the addition of the number at the end of the TempFolder path?

My problem is this:


Our MSI installs to the TempFolder, before a VBScript CA moves it to the proper installation locations. The files are installed to "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\" but when I reference session.property("TempFolder") in the VBScript CA, it returns "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\".

We have tested this on XP workstation and the "1\" is not appended, yet on Win2K3, we have got "Temp\", "1\" or "2\", depending on the server.

This random generation is causing the installation to break.

We are using Windows Installer 3.1.

I have confirmed the property ApplicationUsers = AllUsers (if this has any baring)

In Windows Explorer, %TEMP% returns "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\" directory

Where is this number comming from?
Why is the TempFolder installation value inconsistent with the VBScript CA value?
How do we stop this behaviour without changing 100's of references to property("TempFolder")

TIA

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 28 May 2007 - 00:14

I don't have an answer for you as to why this number appears - perhaps it is related to the media table and disk id's?

However, did you try using the support files view instead? From the Installshield help file:

"Support files are files that are available on the target system only during your application's installation process. Support files are copied to a temporary directory on the target system when installation begins and are deleted when the installation is complete. The support directory (SUPPORTDIR) is a dynamic file location and might be different on every target system and even on the same system for different installation instances. "
Regards
-Stein Åsmul

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 28 May 2007 - 00:44

I've seen these "1\" and "2\" extensions appear in Terminal Server sessions, maybe that's an explanation?
Note: In Windows XP, Fast User Switching is implemented like a TS session.

woter324

woter324
  • Full Members
  • 18 posts

Posted 28 May 2007 - 23:54

Zweitze,

All test installs have been on Win2k3 server through an RDP session. I have just done a test install from the console that has worked. So now we know what is the root cause of the problem, but still need to find out why InstallShield or Windows Installer are changing the values of TempFolder half way through an install.

Insidently, this call is also with Macrovision Support and they asked me to confirm the values of user Env Variables. I did some comparisions between %temp%, set and user env. variables. The user Env Variables come back with /1 or /2, whereas %temp% and set do not.

I'll keep you posted with what Macrovision Support come back with.

Thanks



woter324

woter324
  • Full Members
  • 18 posts

Posted 29 May 2007 - 00:18

I've found this link on URL=http://207.46.196.114/windowsserver/en/library/2955fe3f-747e-46a6-8825-eb9eb7baacae1033.mspx?mfr=true]Technet[/URL]

I guess I can create a custom action to run "flattemp.exe /enable" if running from terminal services. A pain and still doesn't explain the difference in the installer.

Thanks

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 29 May 2007 - 13:17

Thanks for the feedback. I'm surprised that %TEMP% retrieves different results compared to the user environment variable TEMP. But please keep us posted.

FWIW I didn't know one could install from remote locations - last time I tried was NT4 TS Edition, where it's not possible. But I wouldn't recommend installing from a remote location anyway. My concern is (see if this applies to you) reboots, esp. immediate reboots - where the installation continues after the reboot. I wonder whether the install indeed resumes after the installing user logs on through a remote desktop.