SSProtect maintains distinct version history for every managed file (this does not currently apply to Email messages). Each time you securely access content, the associated file Version is incremented (on Close). You can view this progression by navigating to the Managed Files/Restore display from the :Foundation Client's icon in the notification tray. Display the Versionlist pane by choosing Versions... from the initial Hostlist display:
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 with additional flexibility in how renaming vs. moving affects results.
Version Chain Policy
Rather than prompt you each time you access an existing item that has been copied/ moved or renamed, SSProtect applies a Version Chain Policy as defined by settings in the License and Components dialog. This reduces workflow interruptions by allowing you to pre-determine the way Versions and managed instance tracking gets handled.
NOTE: When vChain Policy is enabled for the Organization, Privileged Users can Disable it for individual Accounts from within the Administer Users interface.
Version Chain Policy Impact
When vChain Policy is Enabled for an Account, accessing an item that has been either renamed, copied, and/ or moved results in the creation of a new managed item with Version = 1. Else, when Disabled, the renamed (or moved, depending on Policy detail - see below) item's Version is incremented and the (potentially changed) filename and/ or file path is associated with the new Version instance.
Version Chain Policy is not applied when accessing shared content. More often than not, shared content is transferred from the Owner/ Creator to a sharing peer on another host computer (but not always). As a result, shared item placement doesn't typically match the location of the original item (in name/ path), so it doesn't make sense to create a new Version Chain. As with any other access operation, filename and path information is retained with the activity record and, as a result, displayed in resulting Reports.
Gaining Access to Version Chain Policy Configuration
You likely need to send email to Support with a request to access Version Chain Policy configuration. By default, configuration is not available in an attempt to maintain simplicity for first-time users.
Note that associated configuration is not extended to Unprivileged Organization Users - only to the Organization Administrator and authorized Delegates (and also Individual Account holders).
Once configuration 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 modify (disabled in the example below):
Enabling Split vChains for Organizations
Split vChains, when checked, Enables Policy activation for Organization Accounts but does not Activate operation for existing Accounts. New Accounts, however, will recognize that Split vChains are Enabled and, as a result, by default Activate Split vChain operation.
Activate Split vChain operation for Organization Accounts from within the Administer Users interface available to Privileged Account holders.
Enabling and Activating Split vChains for Individual Accounts
This procedure is slightly different for Individual Accounts since they are self-managed. In this case, checking (enabling) Split vChains also Activates Split vChain Policy for subsequent activity.
In both cases, you will be prompted to confirm changes before a required Refresh Login that applies changes. You can, at that time, return to the License and Component interface to adjust the additional settings that govern Split vChain behavior (when Active for an Account).
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. When not selected, moving a file then accessing content maintains the existing Version Chain.
Changes to this option immediately apply to all Organization Accounts operating with Active Split vChain Policy (or your Individual Account): Refresh Login is not required.
Exclusive Hostlist does not require vChain Policy operation, and is available when Version Chain Policy controls are enabled. This option impacts the Hostlist that shows all managed content for an Account's Host Computer, displayed from the Managed Files/Restore notification icon menu.
This setting is most suitable when Split vChains is not Active, as operation will then have a more direct and visibly related impact to the result of working with files that change names and/ or locations while maintaining the same Version Chain over time.
This setting is is also helpful when working with multiple folders that host the same managed file. When Exclusive Hostlist is chosen, Hostlist managed file enumeration 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 enumerate and display both items, which can be confusing.
NOTE: Items with the same name, but different Version Chains, will be displayed whether or not you're using the Exclusive Hostlist option. 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.
This setting is currently globally applied to all Accounts in an Organization, and changes are immediate without the need for Refresh Login.
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.6.5 of the :Foundation Client