1

I've come across a project that builds an MSI package. One of the folders from that package has this name:

%P_%F_%Path%alfa

At install time, during InstallFiles standard action, Windows Installer will resolve the substring %Path% as an environment variable, thus the character ':' appears inside the folder name and the installation errors out (invalid char in folder name).

EDIT: The same error occurs for DuplicateFiles standard action too.

If I create an MSI that creates this folder empty (i.e. during CreateFolders standard action) Windows Installer does not try to resolve the substring %Path% to an environment variable and the installation succeeds, creating the folder with the name presented above.

I never met this situation before. Anybody else did? If yes, can you give more details about what is going on exactly and if there is a workaround available?

Note! I added all the tags of different MSI authoring tools because I suspect this to be a tool independent situation.

Bogdan Mitrache
  • 10,536
  • 19
  • 34
  • 1
    The docs for "formatted" indicate that you could escape the % by encoding it as [\%] which seems to work in my limited testing. – PhilDW Mar 06 '15 at 18:24
  • Indeed, formatted supports escaping chars like this. But Directory table has no formatted columns, '\' char is not accepted in a valid folder name. https://msdn.microsoft.com/en-us/library/aa368295%28v=vs.85%29.aspx – Bogdan Mitrache Mar 09 '15 at 06:55
  • Understood of course, but if InstallFiles is applying formatted rules in the resolution of your path, it was worth a shot to see if it would apply the [\] rule. – PhilDW Mar 09 '15 at 18:05
  • I tried it, modified the row in Directory table, but the installer errors out during Costing operations complaining about the invalid path. Well, it seems that this is just another WI bug that we'll have to live with. Thanks for all the feedback guys (Christopher, Phil) – Bogdan Mitrache Mar 10 '15 at 06:40
  • MSI is what it is. IMO, it's still the best framework / paradigm to build off though. – Christopher Painter Mar 10 '15 at 18:28

2 Answers2

1

I can confirm, using WiX and IsWiX. IsWiX authors a folder with a file like this:

   <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="MergeRedirectFolder">
        <Directory Id="owd6248671CA393CCC018715A2FB53AD2D6" Name="%P_%F_%Path%alfa">
          <Component Id="owcA59F51CBEAEE88B00B715AF4FEE6BF72" Guid="1619af96-1b2b-64ea-91f5-1a297c3c636a">
            <File Id="owfA59F51CBEAEE88B00B715AF4FEE6BF72" Source="$(var.SourceDir)\test.txt" KeyPath="yes" />
          </Component>
        </Directory>
      </Directory>

IsWiX authors an empty folder like this:

  <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="MergeRedirectFolder">
        <Directory Id="owd6248671CA393CCC018715A2FB53AD2D6" Name="%P_%F_%Path%alfa">
          <Component Id="owc6248671CA393CCC018715A2FB53AD2D6" Guid="071c27cb-0566-40b1-9a50-5672b3fbd5e1">
            <CreateFolder />
          </Component>
        </Directory>
      </Directory>
    </Directory>

Both create MSI's that compile and pass validation but the folder with a file gives the error you describe while the folder with the CreateFolder element works.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
1

Forbidden Folder Names: Interesting, all sorts of pecularities. This is not as much an answer, as a couple of further pointers for MSI folder name peculiarities. Did you know that you can't create folder names with any of the following names in Windows Explorer? con, prn, nul, aux? The list goes on with lpt0 to lpt9 and com0 to com9.

Device References: This is all for legacy reasons. You can't make folders that have "System Action" or "Device" references. These names are old devices and legacy concepts. Device names were recognized before path names. CON was the console device, AUX was the auxiliary device, PRN was the printer, along with LPR<digit>. COM<digit> refers to a com port. There are others. Note that these names ignored the file extension such that CON.EXE or con.txt still meant the console.

Tool Handling: I believe you can still create such folders with Win32 API calls or even with a command prompt, but they are not valid Windows names allowed in Windows Explorer. Incidentally it seems Advanced Installer and Installshield allow them as MSI folder names, but you get runtime errors whilst installing - or you get a warning that a folder name is invalid on MSI launch. I understand the desire to not add code to disallow such folders in the tools - there are always new bugs possible when you start to protect against things like these - rather people should know about these folders I guess. Actually a compile time warning would be great - just a list of illegal folder names to check, and illegal character sequences. It sure is an odd problem to discover when you don't know what is causing it.

Some Links:

Sources (I copied so much from some of these, that they should be listed for reference):

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164