The App-V engine picks up for this (through relationships in memory) and the operations are redirected to the appropriate converged locations in both the User VFS COW and Package Store. You can see examples of these in the following screenshots from Process Monitor:Īs you can see above, the query to the initial location of where the virtual applications thinks it is browsing (C:program Files (x86)Java) is clearly not natively where it thinks it is. VFS COW (Copy-on-Write) checks and locations
Integration junction points to the Package Store What you will have to understand is that once the operations to where the application “thinks” it is located has been hooked in the file system and/or registry every subsequent operation will continue as such to include operations only to the: Why just that? Because that’s where things “actually” are located. In Version 5, running Process Monitor as normal will capture access to the actual locations including registry, package store, as well as VFS (Virtual File System) COW (Copy-on-Write) locations. In App-V 4.6 and earlier, if you did not launch process Monitor in the virtual application’s environment (usually through a command prompt) all you would capture related to the virtual application would be operations to file and registry resources outside the virtual environment. The reason behind this is simple: unlike previous versions of App-V, the REAL registry as well as the native file system – NTFS – is used in App-V 5.
You could run process Monitor inside the virtual bubble, but it will not yield you much more results. If – by that question you want to know if you must start an instance of Process Monitor within the virtual application like you did in 4.x – no.
0 kommentar(er)
