When we capture installer activity for the purpose of creating a package to deploy on another device, the possibility of causing new issues exist. We rely on the tools that we use for the capture/packaging, the runtime environments we use on the target, and the “smarts” of the person doing the packaging to avoid these issues.
Two potential issues that we don’t talk about much are Long Paths and Short-Names. Recent activities with two different customers helped to highlight the need to talk about these topics. .In this article, I will talk about Short-Names.
The previous article covered Long Paths here: https://www.tmurgent.com/TmBlog/?p=2900
When files and directories are created in NTFS (except as noted later), the file/directory has a name plus a short-name. Short-names comply with the original DOS file naming format of no more than 8 characters, period, and up to three characters.
Most often, the short-name is created from the long name by taking the first 6 characters of the long name and, if there are more characters, adding a tilde 1 (as in “~#”) to the end. The extension portion is usually just trimmed to 3 characters. The Short-Name must be unique among the files/directories of the parent folder. So the first file in a directory that has the 6 characters will have ~1 added, and when there already is a ~1 file in the folder the short-name will bounce to the next available number, such as ~2.
More recently Microsoft made short-names optional in the NTFS filesystem. A difference between this setting between the capture system and deployment system can cause problems, but when used on both systems we can have issues as well. If the capture system attempts to bring along the captured short-names they may not be available on the destination, and if not delivered a file short-name might have to be created differently. Problems for all of these cases occur when the application stores the short-name in the registry. Older programs that use COM are the most likely to do that. And the result is that files are not found.
Short-Names and App-V
When short-names are used on the capture system, App-V will capture short-names, but rename the short-name using a different renaming scheme. App-V will replace the short-name with a randomly generated name (a technique that is more random than even a GUID) and it will also replace any registry strings containing the original short-name to use this new name. App-V caries these names in the FileSystemMetadata.xml file inside the package.
If short-names are not used on the capture system, App-V still generates random short-names.
If short-names are used on the destination system they are applied when the package is published, otherwise they are ignored.
My recommendation to customers delivering older software with App-V is to enable short-names on NTFS clients machines.
Short-Names and MSIX
MSIX does not capture or deliver short-names. This may cause issues with certain older packages. There are no known “general” solutions to this at this time.