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.<\/p>\n\n\n\n
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. <\/p>\n\n\n\n
I will follow this article up with an article on Short-names here: https:\/\/www.tmurgent.com\/TmBlog\/?p=2902<\/a> About Long Paths<\/strong><\/p>\n\n\n\n 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. <\/p>\n\n\n\n Long Paths and App-V<\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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<\/a>) . 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. <\/p>\n\n\n\n Some App-V customers also configure the “C:|ProgramData\\AppV” folder to a shorter string to aid with path lengths as well.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Long Paths and MSIX<\/strong><\/p>\n\n\n\n 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. <\/p>\n\n\n\n If we have long path issues with MSIX, the first course of action would be to keep your package name short.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" 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… Continue reading Long Paths and Recapture<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[47,53],"tags":[31,52],"class_list":["post-2900","post","type-post","status-publish","format-standard","hentry","category-appv5","category-msix","tag-appv5","tag-msix","entry"],"_links":{"self":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts\/2900","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2900"}],"version-history":[{"count":2,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts\/2900\/revisions"}],"predecessor-version":[{"id":2905,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=\/wp\/v2\/posts\/2900\/revisions\/2905"}],"wp:attachment":[{"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2900"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2900"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tmurgent.com\/TmBlog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2900"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
<\/p>\n\n\n\n