Right-click commit files/folders + memory cache ?

I currently use Shadow Defender, which is small and stable on my system, but unfortunately doesn't seem to be developed any more. Returnil looks like a possible new option, although I only interested in the freezing/snapshot features, and not interested in the anti-virus features.

One big feature missing in SD is the ability to only use RAM as the cache, so no writes are made to the disk at all. SD also has right-click context menu item for committing changes (including optional deletions).

I've read that Returnil has a memory cache - does this mean only RAM is used for the cache and no writes will be made to the disk at all (including the OS paging RAM memory to disk) ?

Also, Returnil has the explorers for viewing and committing changes to the file system and registry. Does it also include a similar right-click context menu option, like SD, for commiting changes from explorer ?

The multi-snapshot technology also looks interesting, so I'll be testing that out too. Does the first snapshot take a long time to create, with the following snapshots being quick as only the differences since the last snapshot are saved ?

How does it keep track of the changes between reboots, and what happens if changes were made to the disk being monitored, while RMS is not running (eg. from another OS installation) ?

If/when you do integrate MS into your other products, please also add it to the normal Returnil Pro edition, as well as the System Safe, since I would like to have this kind of snapshotting technology, but without all the cloud anti-virus technology.

 

I second that.

 

Hi Defenestration and welcome to this part of the forums

First, MEMORY is RAM + Disk in this context.

RVS 2007 and 2008 were designed as both production releases but also as technology demonstrators for the virtualization technology that is still evolving as we go forward. In these earlier generations, we were exploring a more robust and efficient way to clone the system through the use of RAM and non-contiguous space for the virtualization cache.

The second focus above was actually the main focus up to the 2007 generation as competitors were still using the older technology where a cache had to be strictly defined in terms of non-fragmented space available on your hard drive. This led to smaller caches and inefficient use of disk space.

This development meant that you did not HAVE to defragment you hard disk to create a cache and there was more space available by default so the use of the virtualization was less cumbersome for the average commercial user.

We then began looking seriously at how we could improve the performance of the virtualization through the use of RAM first and then disk for change tracking due to the obvious performance benefits that would introduce. We succeeded and this led to the 2008 series where you had a choice between Memory caching OR our more advanced disk caching approach. During the early beta testing however, we ran head-first into the limitation that memory based caching can have when it encounters a very large number of concurrent changes or very large files: increased potential for file damage.

This is why we stripped the ability to save content to disk when using memory caching in that generation and began research into how the two techniques could be combined in a way to retain the best properties for each (memory was a better performer while strict disk was more reliable as far as saving changes). This led to the DYNAMIC caching approach used in the current RVS Lite, RVS Pro, and RSS Pro/Free 2011 versions where the cache configuration was simplified to the authorized user deciding the maximum percentage of available free space on the system partition the cache would be able use. So you can think of the new dynamic caching as RAM first then disk but with the reliability of the older strict disk caching approach.

be careful here. Selective change saving to disk is available for files and folders but not the registry itself. This is for both security as far as unintended/unwanted changes, but also for performance reasons. It is much less resource intensive to monitor changes in selected (read: pre-defined in the File Manager) than to run a continuous monitor that would be required to track changes in the registry in the same way.

Registry changes CAN be committed to the real disk but only through the use of the advanced setting to "save all changes" which is meant as a convenience for remote management scenarios where the admin is completely aware of all the changes that are going to take place and has authorized the changes to be made permanent (ref: remote profile update; program update for a system in an inconvenient physical location; etc).

With that said, the use of a shell extension, though convenient, is risky; especially for novice and average users who are likely to not have the experience to know whether file "X" or change "y" should be saved to disk. Think of the usual process where a novice user goes to install that new shiny program making the rounds and how it is probable that the user would simply click through all those screens without paying attention to what they are doing and what the consequences might be; "Well my brother's sister's uncle said it was ok...!" kind of vetting going on in other words.

With the File Manager the user needs to define exactly what needs to be saved and in so doing, gets a better idea of what the computer and their programs are doing and what is needed to ensure that the computer stays protected while allowing them to use said program.

This can be tedious (and was up until recently) and is the reason we developed the Autosave functionality in the FM (try REL13 builds) so the user could simply define their game folder, Documents, pictures, Favorites, etc system folders and all their contents including sub-folders to give the user a more seamless and enjoyable experience.

The snapshot technology in the RMSU is based on our virtualization technology and the snapshots take mere seconds to create. Reverting to a specific snapshot however can take a period of time depending on the number and size of the changes between what is there now and what was in the snapshot. This approach also allows you to selectively "undo" your snapshot reversion by allowing you to recover files from the previous machine state just prior to the snapshot recovery.

Like the Virtualization in RVS/RSS, the RMSU is tracking changes in a cache. This cache has a maximum size and once that size is exceeded, the oldest snapshot will be "lost" to make room for the most recent snapshot. In the scenario you propose, the RMSU would simply see the changes as the current system. IOW's, if you applied a snapshot, the RMSU would simply take your system back to what it was as detailed in that chosen snapshot while allowing you access to specific files to recover from the previous machine state as described previously.

Mike