Global Exclude Entries
Updated: 29 Jul 2010 | 10 comments
It would be nice to have the ability to globally exclude a directory or file type from being captured, such as [DESKTOP] or .DOC files. This would act similar to data layer but instead letting the data fall to the base instead.
Idea Filed Under:
Comments
Sounds good
What you mentioned above sounds good. I'd also love to be able to choose between two different models.
1.) Data written by a process in a layer is captured to the r/w sub-layer unless a data layer or exclude exists. (Current behavior great for encapsulation of data with an application)
2.) Data written by a process in a layer falls to the base unless it is targeted for a directory that is part of the processes layer. (For environments where local data persistence is more of a priority then encapsulation)
Essential feature
Being able to specify gobal exclude directories is actually an essential feature. It should be _very_ easy to use.
Simply select the directories in the GUI that should be written directly to the base system, (e.g., Desktop and My Documents), overriding any settings in the layers.
It is possible to achieve that today already, but WAY too complicated.
GUI interface options needed
First off - excluding specific directories from being written in the layer is an essential piece and it should be in the properties page on a layer after you set it up and click on it in the Manager.
Second- does anyone know how to exclude My Documents and the Desktop now?
Exclusions
About your question about exclusions:
My Documents = [PERSONAL]
Desktop = [DESKTOP]
----
Masi
----
Masi
Solving my own issues
I found that you can also do exclusions with the [SYSTEMDRIVE]\ to exclude your primary Windows partition in its entirety or [USERPROFILE] to exclude your user folder which is handy for programs like Office and Firefox - they can write to my docs, desktop, favorites, temp Internet files etc.
I recommend a more
I recommend a more strategic approach to exclude entries. If you exclude [SYSTEMDRIVE] you will loose the ability to reset an application since the files that should be going to the writable sub layer are being written to the base. Many people exclude [USERPROFILE] in order to maintain user settings after a reset. Instead of exclude entries you can also use data layers.
Jared Payne
Software Engineer
Jared Payne
Software Engineer
Data Layer Feasability
How useable are data layers? What if I have a user who wants to give SVS a swing but then decides against it and all his data is in a data layer? What if I get a data layer that is corrupted? I lose all of my documents instead of one?
I guess I'm still not sold on the concept of data layers...Feedback please.
Data Layer Feasability
Take a look under c:\fslrdr. You'll see that everything in layers is there, for real. Same ACL's and everything. No compression or encryption or any other funny business (tho encryption is a likely candidate as a future -- optional! -- feature). So there is no opportunity for "corruption" beyond the normal risks you would have w/o SVS. Uninstall SVS and you can still go get things out of the redirect area.
Scott Jones
Product Manager
Altiris, Inc.
Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation
www.symantec.com
What is the best way to
What is the best way to exclude files without knowing their location?
For example. if I create a layer for the WINZIP program, how can I manage the files created during unzipping command?
Thanks
Exclusions
The best way to prevent data from staying in layers at home is to exclude the local harddisks in every layer.
For the office there is no need to create exclusions if your people are putting data on the network. UNC paths to drives are excludes automatically.
Regards Erik
www.svs4u.nl
Regards Erik www.DinamiQs.com Dinamiqs is the home of VirtualStorm (www.virtualstorm.org)
*************************************************************
If your issue has been solved, Please mark it as solved
***********
Would you like to reply?
Login or Register to post your comment.