Investigating for Dirty Virtualization
Having virtualized a lot of programs, I sometimes get the impression that fslrdr folder size is increasing abnormously with its use.
The problem could depend on a dirty virtualization: in fact in such a case it could happen that a program folder increases at every new activation.
You could be obliged, to know which is the wrong installation, to inspect many direcories/subdirectories of fslrdr, looking for the one collecting excessive data: a painfull task as every virtualized program generates a plethora of subfolders, many of them empty and some full of subdirectories; furthermore SVS does not maintain a clear match within the name of your program, or the name that you assign to the virtualized prgm, and its subfolder in fslrdr.
A problem investigation can be more easily made by the use of FolderSize, a freeware prgm that, in a way similar to Explorer, permits the inspection of different folders, adding their size to the information.
Starting with size it is quite immediate to find the name of a virtualized prgm, as the Program name (the file of the program itself) is usually included in one of the biggest folders of each fslrdr subdirectory: i.e the PROGRAMFILES folder.
As the majority of other directories should be generally much smaller, it is not difficult to identify the problem (the exception) and to virtualize again the prgm identified.
Folder Size 1.3 does not require installation, so you can directly put its .exe file on the Desktop, and can be freely downloaded (400k)from here: http://sixfiles.com/dbase/files/rotebetasoftware-f...
Do we have a defect?
I'm not clear on what you mean by "dirty virtualization," "program folder increases at every new activation" and "wrong installation." Are you saying that you've observed SVS making duplicate copies of a program files folder in the redirect area every time a layer is activated? Can you give us a specific example, with steps to reproduce -- which app? all apps? Have you contacted Symantec Support or posted to the SVS support forum on this?
I'm not sure I've ever seen this or anything like it with release code. We should get to the bottom of what you are observing.
Dirty Virtualization
Thanks for your comments, unfortunately I am no more in condition to say which virtualized prgm gave me some problems.
Migrating from SVS 2.o to 2.1, months ago , I noted that under the Virtual directory Systemdrive some subfolders was present, sometimes containing different Mb, from 1 to more than 50Mb, generally named \Recycled\Nprotect or \System Volume Information \Restore..... and that seldom those figures increased during the use of the program. The programs could have been some demo of 3dsmax or Photomodeler or some game, I don't remember. I asked Altiris what to do before migrating, moving all automatically or delete those sort of recycle bin before making .vsa files: the answer was that in principle those informations could be ignored, so then I deleted them when files was to big and all was ok, until now.
The only difficulty was to see if those "bin" were present and how big, that was the reason for my suggested tip.
Could it be usefull to arrange SVS so then, if required to do so, all not necessary informations (like Nprotect info) are automatically deleted during vriting of .vsa file? that could be a solution I believe, Reset the layer is not the same in case such info are generated during the virtualization process; an other solution could be to maintain Unerase Wizard (Nprotect I suppose) clean and delete maually all file deposited there by a just activated virtual program.
Thanks again for the unvaluable SVS, I multiplied times three the period within one restoring of the computer and the next, and could be I could continue much more time.
Fenny
layer maintenance
I've noticed that some virtual applications can indeed collect a fair bit of noise over the months. In the real world these changes would go unnoticed and probably just end up slowing down your app and your machine, but not with SVS.
All these changes end up in the RW sublayer, so if you thought about layer excludes, a reset will revert you to a shiny new application in seconds. I'm even scheduling layer resets for some of the noisy apps.
If you are still concerned about extra data or your system seems to run low on disk space, e.g. after an msi repair, Search the Juice for 'SVS LayerSize Analyzer', and then order by RW size and you will soon find out where your disk space has gone if it ended up in a layer.
For a more granular approach I'd use something like TreeSize Professional.
Regards,
Marco
So Problem isn't related to SVS
So if I understand correctly the problem isn't related to SVS, but in fact SVS is the solution. Some apps just happen to clutter windows and by resetting a layer that solves the problem.
If I've got this right then we should probably rename the article to avoid confusion.
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
WinDirStat
A project hosted at Sourceforge is a windows version of an old *nix program. I think it is vastly superior in figuring out where disk space is disappearing to. The Sourceforge project page is at http://sourceforge.net/projects/windirstat/ but its actual main home page is at http://windirstat.info.
Recommended
I have used WinDirStat ever since I found a copy on a CD accompanying a “world’s best” utilities article in a popular PC magazine. It’s a wonderful program; a major timesaver.
Would you like to reply?
Login or Register to post your comment.