Programs from base modifying layers
jz81
October 29th, 2009
We are currently experiencing some problems with programs installed in the base modifying layers.
Process A: image is in the base
Process B: image is in layerB
process B
|
|__> Process A
When launching process A from process B, all modifications done by process A are saved in the writable sublayer of layerB. I realize this is by design. Is there any way to avoid inheritance of the layer priority list by process A? (other than putting the image of process A in the programignore reg value because this implies that process A can't see layerB)
Thanks,
John
What is the layer priority of
What is the layer priority of Process B set to ?
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Does it really matter ...
The layer priority of LayerB is 85.5. But I'm not sure that it even matters in this scenario. As far as I have seen process A will always inherit the priority table of process B.
You should be able to set the
You should be able to set the priority of the base over the layer so applications in the base will see the base first and then the layer.
If a forum post solves your problem please flag is as the solution
I you like an article, blog post or download vote it up
Priorities don't change
Priorities don't change anything here. If the parent process is virtual, all sub processes are by design virtual, right?
For example, run solitaire from a layer and change the deck, the registry settings always end up in the layer.
"Autorun from base" would be a great way to avoid this. Basically the opposite as autorun, a process should always be run from base instead of a layer no matter how it was launched.
So wait. You want a process
So wait. You want a process that's inside the layer to act as if it's on the base? that's different from what we've been talking about before, and has nothing to do with priority, and honestly that kind of defeats the purpose of even virtualizing the application.
Just set up some excludes if you don't want things to get captured into a layer.
If a forum post solves your problem please flag is as the solution
I you like an article, blog post or download vote it up
Hang on ...
We were talking about a process with an image in the base that was launched from a process with an image in the layer.
An example:
We've got Office in a layer. If I receive a .txt file attached to a mail message in Outlook and I double-click it. I modify it and then save it. It will be saved in the Office layer.
This can be very confusing for end-users, because if I first save the file (in the layer) and subsequently open it using notepad, modify it and save it, the file will be saved in the base.
ya that's what excludes are
ya that's what excludes are for, to prevent file types or locations from getting captured inside a layer when modified by a process in a layer.
Check out layerExcludeFinder for an easy way to generate file type excludes.
If a forum post solves your problem please flag is as the solution
I you like an article, blog post or download vote it up
Automatic exclusion for base apps?
I think what we are asking about is whether if it is possible for all file/registry activities by a base application to go into the base system when the base application was started (i.e. launching it with a file, or URL) from a SWV-ed program. This can happen as we may have certain programs that we decide not to put under SWV layers, and having to put exclusions for them can be a hassle. For example, if the base program by nature is a file-management program, it will touch and manipulate files all over the system so setting file exclusions for it is impractical.
As it is, it seems that the only way to overcome it is to start up the base program first. Then later if the SWV apps interact with it, nothing gets redirected into SWV layers.
However, I did notice this article: https://www-secure.symantec.com/connect/blogs/delv...
Will setting priorities provide the functionality needed?
Would you like to reply?
Login or Register to post your comment.