SSProtect maintains distinct version history for every managed file (this does not apply to Email messages). Each time you securely access content then close, the associated file Version is incremented. You can view this progression by navigating to the Managed Files/Restore notification icon menu then selecting the target file of interest and clicking Versions...:
New Instances or Continued Versions
If you copy a managed file, rename it, then open it for editing, what version does it carry on close? There are valid reasons to continue the Version Chain with the renamed file, and also valid reasons to create a newly managed entity and begin with Version 1.
SSProtect supports both options, and allows you to decide how folder movement impacts Versions.
Version Chain Policy
Rather than prompt you each time you access an existing item that has been moved, renamed, or copied, SSProtect applies a Version Chain Policy as defined by settings in the License and Components dialog. This reduces workflow interruptions and allows you to decide, for you and your Organization, how you want to work with managed content.
Default Version Chain Policy
By default, accessing an item that has been either renamed, copied, and/ or moved will result in the creation of a new managed item at Version 1. It's important to note that the new entity is not created until after you securely access the moved/ copied/ renamed target and close (save) the file, else all file operations would be subject to authentication and authorization requirements or available to attackers - both insufficient UI realities.
Version Chain Policy is not applied when accessing shared content. More often than not, shared content is transferred from the Owner/ Creator to the sharing peer on another host computer (but not always). Shared items can thus be placed anywhere in the filesystem and also renamed - each access increments the Version count, and Audit Records will show (to authorized users) the full path of the file as it existed at that time.
Gaining Access to Version Chain Policy Configuration
You must first send email to Support to request access to Version Chain Policy. This is an item not by default available for modification, as its' impact is far-reaching (all Organization Users) and may not be easily understood when first Evaluating the system.
Configuration cannot be extended to Unprivileged Organization Users - only the Organization Administrator and Delegates, or an Individual Account holder. Each Support request enables Policy editing capability for one or more Privileged Organization users, whose access is individually managed.
Once access is granted, Refresh Login from the notification icon's menu then navigate to the License and Components dialog. Version Chain Policy controls will be available for you to change.
NOTE: Version Chain Policy changes apply to all Organization Users.
Split vChain Policy, when set (the default), creates a new managed item anytime you copy/ rename an existing item then subsequently access and close (save) it. If you de-select this checkbox, you will be prompted to confirm the understanding that Split vChain Policy gets subsequently removed for all Organization Users. This goes into effect the next time each User performs Login to establish a new SSProtect Login Session.
The Move Splits option is only viable when Split vChains is enabled. Move Splits, when selected, applies Split vChain policy execution to items that are moved or copied to other folders - but retain the same filename.
Choose the option you prefer for your Organization Users then respond to the confirmation prompt. This feature does not require that you (or other Organization Users) Refresh Login for changes go into effect - the change is immediate.
Exclusive Hostlist does not rely on other settings, and is available when Version Chain Policy controls are enabled. This option impacts the Hostlist that shows all managed content for your current Host Computer, displayed from the Managed Files/Restore notification icon menu.
This can be useful if you are working with multiple folders but end up with the same managed filename in each location. When Exclusive Hostlist is chosen, it will only display the last-used instance of any item in a Version Chain, even if a previous version carries a different filename and/ or folder. When de-selected, the Hostlist will display both items.
Toggling this setting restores context, i.e. the change applies visual filtering and does not impact the underlying reality of managed items.
Finally, remember that items with the same name, but different Version Chains, will be displayed in both cases. Adjust this setting based on the way you use related Version Chain Policy controls, as that will have an impact on the frequency of name collisions and a need to either isolate Version Chains or show multiple instances.
Examples for Version Chain Policy Impact
The use of Version Chain Policy controls can be confusing, and this section shows you exactly how these controls affect behavior.
Default - Split vChains
First, start with default settings - we're primarily focused on making certain Split vChains is selected. Create a file called vChain-Original.txt, and protect it to create Version 1. View this instance in the Versionlist by navigating through the notification icon's Managed Files/Restore menu item, choosing the target file in the displayed Hostlist, then selecting Versions.... You will see the single instance you just created.
Go to File Explorer and make a copy of this file in the same folder - we'll call it vChain-Original-Copy.txt. Open and close it (with or without changes) and return to the Versionlist display and click Refresh. Notice that nothing changes.
If, however you return to the Hostlist (by clicking Host List...) you will see both file instances. Choose the copy then Versions... to see the newly created Version 1.
Disabling Splits vChains
Let's repeat this example without Split vChains - first send email to Support requesting access to modify Version Chain Policy, then when you are notified this has been configured for you, Refresh Login and navigate to License and Components then de-select Split vChains. You will be prompted to acknowledge the request and forced to Refresh Login (yes, again) at which point we can repeat the previous steps to see differences.
Create a new file which we'll call vChain-NoSplit.txt. Open and close this file, then view its' Version 1 in the Versionlist. Again in File Explorer make a copy of this file, vChain-NoSplit-Copy.txt, then be sure to open/ close the new copy before returning to the Versionlist to click Refresh. Notice this time there are two Versions for this file.
Return to the Hostlist and you'll also notice there both instances are displayed. Choose the original vChain-NoSplit.txt then Versions.... Notice the same two instances are listed - you have two files in the Hostlist that represent different version in a Version Chain.
Impact to the :Recover Archive
If you're using :Recover, you'll notice that this setting has a similar impact on the Archivelist (as you may have suspected). Choose Archive... from the Managed Files/Restore display we've been using for Hostlist/ Versionlist visibility, then note that you see two instances, one each for the files we created when working with Split vChains - however you will only see the copied instance of the second file we worked with after disabling Split vChains. You can choose any of these files and navigate back to the Versionlist to see the same results we viewed navigating from the Hostlist.
Displaying the Latest Version
It's important to remember that, when disabling Split vChains, the Archivelist will present the last-used instance for the local host. As you may have guessed, if you now open/ close the original from the second example, vChain-NoSplit.txt then return to the Archivelist (or use Refresh when still there), you will see its' instance instead of vChain-NoSplit-Copy.txt.
Exclusive Hostlist Impact
If you set Exclusive Hostlist, you will for files managed without Split vChains achieve the same result we observed in the Achivelist when we revisit the Hostlist - only one instance, the latest, will be presented in the file enumeration. If you enable/ disable Exclusive Hostlist, the Hostlist will switch back and forth between presenting all related instances and the lastest Version in a single Version Chain - it acts as a display filter and has no impact on the underlying relationships.
It seems hard to imagine that any one configuration default will serve all purposes. The Move Splits setting is a simple way of scoping the Split vChain mechanism (when set) if a file is moved or copied to another folder while retaining the same filename.
Is this as expected, suitable, too complicated, just right - or do you have suggestions? We welcome any and all feedback on the best and most suitable path for your needs.
For More Information
For information regarding product features and content, consult the Document Index, or send email with specific questions to firstname.lastname@example.org.
This article was updated w/ v9.4.2 of the :Foundation Client