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 Long Paths.
I will follow this article up with an article on Short-names here: https://www.tmurgent.com/TmBlog/?p=2902
About Long Paths
Originally, file paths were limited to 256 characters. Microsoft extended these limits long ago, but some applications continue to use file interfaces that are limited to the 256 limit.
Long Paths and App-V
When recapture packaging for a runtime like App-V, the client environment causes the locations of files to automatically have a longer path due to how the packages are deployed. When compared against the path of what was captured, this adds about about 100 characters to the length. For example, if a file was under “C:\Program Files” App-V deploys these packages under “C:\ProgramData\AppV” and adds a couple of GUIDs plus a Root and VFS folder and variablized folder name instead. This can push some apps file paths to exceed the limit if they use the older Windows API calls.
To combat this we started using techniques like PVAD to cut that number down a little to solve the problem (see https://www.tmurgent.com/TmBlog/?p=2264) . The PVAD shortens this added path length by 20-25 characters in all cases, but if the app tries to access the path in certain ways it completely eliminates the overhead by implementing a hidden link, letting the app make the request exactly as it would have origiginally.
Some App-V customers also configure the “C:|ProgramData\AppV” folder to a shorter string to aid with path lengths as well.
Sometime back, Microsoft implemented changes in App-V to dynamically convert the file requests to use the longer path methods. This “conversion” is simply to add the string “\\?\” in front of the file path requested; this is a trigger for NTFS to support the potentially longer paths. This conversion solves most long path issues, however it is always possible that older vendor code might have a internal assumption in memory allocations that remains a problem.
Long Paths and MSIX
When recapture packaging for a runtime like MSIX, the paths also look longer than the original, but typically by a smaller amount. The amount for MSIX will be 18 characters plus the size of the full package name (the display name with bitness, version, and publisher-hash), so not as much as App-V but potentially a problem.
If we have long path issues with MSIX, the first course of action would be to keep your package name short.
MSIX does allow you to specify the installation directory (the equivalent of PVAD) which can help a little for all file accesses like App-V, but unlike App-V there is no hidden link.
At this time I don’t know if the MSIX runtime also automatically adjusts paths using the “\\?\” technique, but I can confirm that PSF redirection using the FileRedirectionFixup shim does do so for any redirected files.
Eventually I hope to determine if the MSIX Runtime has the App-V like solution in place generally, and if not a PSF solution should be possible to build.
