[wix-users] Controlling Updates of unversioned files
Todd Hoatson
todd.hoatson at gmail.com
Mon Mar 8 08:40:38 PST 2021
jhg7We have run into a problem with some files that have been updated, but
they don't get installed on some users' systems.
The files in question are not versioned. We have some text files that we
install, as well as some zip files. Our current problem is with the latter.
One oddity with the Windows file system is seen when I copy a file
manually: One copy of the BYZ.p8z file has a Created date of 1/8/2019 and
a Modified date of 7/24/2020. When I copy it to a new folder, the Modified
date of the copy is the same, but the Created date is 3/5/2021 even though
this does not match the Created date of the original file, nor is it
today's date.
This makes it difficult to control my test scenario...
So, with this file (BYZ.p8z) copied to the install location on my system, I
attempt to install a new version of the product. This installation
successuflly updates the BYZ.p8z file to have Created date 3/5/2021 and
Modified date is the same.
I start over, copying the BYZ.p8z file to the installation location. This
time the file after copying has a Created date of 1/8/2019 and a Modified
date of 7/24/2020. (This is to reproduce the situation on some users'
systems where the file has a Modified date later than the Created date.
It's not yet clear how this situation came about.)
Using the Windows Apps and Features tool, I choose to Modify the
installation in order to update the back-level file I just copied. When
the installer starts, I click on Repair. But the back-level file is not
updated! Only if I delete the BYZ.p8z file from the install location will
repair copy the correct file.
After a bit of research, we found the information on File Versioning Rules
- Win32 apps | Microsoft Docs
<https://docs.microsoft.com/en-us/windows/win32/msi/file-versioning-rules>,
where I read:
"Nonversioned Files are User Data—If the Modified date is later than the
Create date for the file on the computer, do not install the file because
user customizations would be deleted. If the Modified and Create dates are
the same, install the file. If the Create date is later than the Modified
date, the file is considered unmodified, install the file."
It seems to be a faulty assumption that Nonversioned Files are User Data,
as this severely limits the kinds of files that can be used for app data.
But this is the situation with the Windows installer, which we have to live
with.
I tried to change/override this behavior by setting the KeyPath attribute
for the file to 'no'. Since we use heat to harvest the files for the
installation, I did this by using an xslt transform, containing the
following lines:
<!-- Specifically, special handling for BYZ.p8z File element -
<xsl:template match="wix:File[contains(@Source, 'BYZ.p8z')]">
<!-- Just copy the tag itself -->
<xsl:copy>
<!-- Generally, copy all attributes -->
<xsl:apply-templates select="@*" />
<!-- Modify the KeyPath attribute to 'No' to turn off version
checking -->
<xsl:attribute name="KeyPath">no</xsl:attribute>
<!-- Now take the rest of the inner tag -->
<xsl:apply-templates select="node()" />
</xsl:copy>
</xsl:template>
I checked the .wxs file output by heat and confirmed that the BYZ.p8z file
has KeyPath="no" and Permanent="yes". Yet when I look at the log file
produced when the installer failed to update the file, I see:
FileCopy(SourceName=BYZ.p8z,SourceCabKey=BYZ.p8z,DestName=BYZ.p8z,Attributes=512,FileSize=3643291,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=-1495337071,HashPart2=-1750950674,HashPart3=1121107855,HashPart4=-1691272291,,)
MSI (s) (B4:90) [15:53:41:311]: File: C:\My Paratext 9
Projects\_Resources\BYZ.p8z; Won't Overwrite; Won't patch; Existing file is
unversioned but modified
Is there any way for us to override this behavior?
thanks,
Todd Hoatson
Mobile: 763-291-3312
Email: todd.hoatson at gmail.com
www.linkedin.com/in/toddhoatson
More information about the wix-users
mailing list