Importance of folder structure consistency across master images and FlexApp packagers
Customer problem:
On a new FPC master image with the latest version of the FlexApp Packaging Console, Chrome x64 would capture and playback locally without issue but after playing it back to a VDI pool the entire "C:\Program Files\Google" folder wasn't visible on the filesystem. Other applications don't seem to exhibit this issue. The packaging machine has Google DriveFS installed but the VDI pool master image doesn't.
Possible resolutions:
Make the related folder structures consistent across the VDI pool and FPC by doing one of the following.
- Uninstall related software, clean up paths and capture the application again, or
- Create it using cmd.exe /c md "C:\Program Files\Google" in a Pre-Logon User Defined Script, or
- Pre-create the "C:\Program Files\Google" folder on the master image of the VDI pool.
Discussion:
Generally, packaging needs consistency in folder structures for applications being packaged/played back. In the past, we would perform conflict resolution on playback where if a folder containing files/folders already existed on the playback machine the service would “lay down” reparse points for every file that didn’t already exist. We moved away from this due to problems in certain circumstances where the OS was not properly removing these “reparse point stub files”. So now the service will only reparse folders and never individual files as a result of conflict resolution. If the capture only saw a file get created in an existing folder – playback would still reflect that, we would lay down the reparse for this single file because it is directly listed in the CAP and not called for as a result of conflict resolution.
I’ll use this Google folder example to illustrate the different scenarios so it’s clear going forward.
1. Google folder exists and is empty on the playback machine and doesn’t exist on the capture machine – GOOD, service will lay the reparse point over the top of the empty folder.
2. Google folder exists and is NOT empty on the playback machine and doesn’t exist on the capture machine – BAD, service may not reparse anything or maybe only the sub-folders and their files but no files in the parent folder.
3. Google folder exists and is NOT empty on the playback machine and also exists on the capture machine, neither with overlapping content to the desired package – GOOD, if they’re consistent in terms of existing structure for the application being packaged without overlapping files – can be bad if not consistent, though.
4. Google folder does NOT exist on the playback OR capture machine – GOOD, the parent folder will be created and used as the main/single reparse point on playback (Best-case scenario / recommended best-practice).
5. Google folder does NOT exist on the playback machine but DOES on the capture machine – BAD, the capture will have an incomplete reparse tree which wouldn’t include creating/reparsing the Google folder because that operation wasn’t part of the capture since it already existed – can be solved by making sure the folder gets created before playback starts.