0

The Bad Result:

A file gets installed with created and modified dates that are different. Future upgrades will not overwrite this file, by Windows upgrade rules.

This happens when a reboot is required after installation due to the file was "held". The file overwrites the old file after the reboot, with wrong dates.

Details:

During a major upgrade, the install log reports file "is being held in use", and "Must reboot to complete operation". Installation completes; recommends reboot; and I reboot. The file is now installed, overwriting the old file. It now has the created date of the previous copy (bad). The modified date is, correctly, the new file's actual build date.

We never saw this behavior with "small" upgrades. In fact, the file did not get held, and no reboot occurred. This major upgrade is a late uninstall upgrade, having RemoveExistingProducts sequenced after InstallFinalize.

This is an unversioned file. It is used by our Windows service, which is not reliably halted by the installer.

Here is the log of the file getting held for install after reboot:

MSI (s) (CC:2C) [14:08:48:575]: File: C:\Program Files\MDI\iTRUST Enterprise\z9\lib\z9-1.0-SNAPSHOT.jar;    Overwrite;  Won't patch;    Existing file is unversioned and unmodified - hash doesn't match source file
MSI (s) (CC:2C) [14:08:48:575]: Source for file '_C7680EB77342823FE55058B9787F76C5' is compressed
InstallFiles: File: z9-1.0-SNAPSHOT.jar,  Directory: C:\Program Files\MDI\iTRUST Enterprise\z9\lib\,  Size: 20043123
MSI (s) (CC:2C) [14:08:48:579]: Re-applying security from existing file.
Info 1603. The file C:\Program Files\MDI\iTRUST Enterprise\z9\lib\z9-1.0-SNAPSHOT.jar is being held in use.  Close that application and retry.
MSI (s) (CC:2C) [14:08:48:585]: Verifying accessibility of file: z9-1.0-SNAPSHOT.jar
MSI (s) (CC:2C) [14:08:48:585]: Verifying accessibility of file: z9-1.0-SNAPSHOT.jar
MSI (s) (CC:2C) [14:08:48:585]: Using source file security for destination.
MSI (s) (CC:2C) [14:08:48:585]: Note: 1: 2318 2: C:\Config.Msi\38d75.rbf 
MSI (s) (CC:2C) [14:08:48:587]: Note: 1: 2318 2: C:\Config.Msi\38d75.rbf 
MSI (s) (CC:2C) [14:08:48:667]: Note: 1: 2329 2: 32 3: C:\Program Files\MDI\iTRUST Enterprise\z9\lib\z9-1.0-SNAPSHOT.jar 
MSI (s) (CC:2C) [14:08:48:667]: Verifying accessibility of file: z9-1.0-SNAPSHOT.jar
Info 1903. Scheduling reboot operation: Deleting file C:\Program Files\MDI\iTRUST Enterprise\z9\lib\z9-1.0-SNAPSHOT.jar. Must reboot to complete operation.

The next upgrade gives the dreaded

Won't Overwrite; Won't patch; Existing file is unversioned but modified

Update: I have asked on InstallShield forum as well. No replies there either.

Saturn5
  • 108
  • 1
  • 7
  • Are you writing to this file somehow during application operation? – Stein Åsmul Feb 06 '20 at 20:55
  • No. It is a library. Java JAR. – Saturn5 Feb 07 '20 at 16:48
  • How has the file been modified? Do you write to it while it is running? Bit stretched for time, [maybe have a skim here](https://stackoverflow.com/a/60854570/129130). Can you change the file name and work to not modify the JAR during runtime? – Stein Åsmul Jun 09 '20 at 13:47
  • The file is never modified (except for overwrite by the installer during upgrade). At runtime it is only read from. Good link. Lot's info for me. OP is slightly off my point, but I will study it. – Saturn5 Jun 10 '20 at 15:53
  • I am not a Java-guy, but there might be ways to ensure that the modify date does not change during runtime - for example to install it read-only? I am not sure - haven't dealt with Java for years. MSI has this idea that unversioned files should not be overwritten if the create and modify dates are different (indicating a modification of the file since it was installed). Note that [Advanced Installer](https://www.advancedinstaller.com/user-guide/tutorial-java.html) has special features for Java installation (potentially handling this problem for you) - Installshield probably has something too. – Stein Åsmul Jun 10 '20 at 16:05
  • [MSI Tools](https://stackoverflow.com/a/50229840/129130). – Stein Åsmul Jun 10 '20 at 16:06
  • Understood. The file, however, does not change nor have it's modify date changed during runtime. It is the installer, only, that sets the dates incorrectly. – Saturn5 Jun 11 '20 at 13:05
  • @Saturn5 any luck resolving this? – yuyoyuppe Jul 15 '21 at 13:15

0 Answers0