Since Silverstack 6.4 file resources (all registered file copies and the source) have a verification state that is displayed in the “File” tab of the right bar.
The verification state helps the user to identify the current verification status of the file resource of a clip. This is especially necessary with the possibility to copy files first and verify them later in a separate job: With verification states it is explicitly identifiable if the resource has been verified.
3 Verification States
A file resource can have 3 different verification states:
Verified (green)
Defect (red)
Not Verified (grey)
Here’s more details about the 3 states and what they mean:
- Verified: The hash of the destination file matches the hash created during the initial copy of the file. For source (source file resources) a green verified state means that they passed “Source Verification” (if enabled), which means a second read and hash check of the source and comparison to the the initially created hash.
- Defect: The file resource has a different hash than the one created during the initial copy. This can be identified by any type of verification Silverstack performs (e.g. as part of a copy job or with a separate verify job).
- Not Verified: The file resource has not been verified. Silverstack did not attempt to do a verification due to settings of the user. This can be the case e.g. for the source file resource when “Source Verification” has been disabled, or for copy destinations when choosing to copy without verification (which we do not recommend).
You can learn more about how the Silverstack copy process works in the following article:
Verification States in the File Tab
The file resources in the file tab show the verification state per resource and as a summary for the clip:
Fig. 1: The file tab with verification indicators
We can see that the clip has 3 file resources:
- Source: Verified
- Backup 1: Verified
- Backup 2: Not Verified
The summary about the clip tells us that the verification is incomplete because at least 1 file resource is not verified. We will take a closer look at this behavior in the next section.
Escalation of Verification States
Fig. 2: Tracing the indicators from the bin to the file resource in the file tab
To make the user aware of the verification state of all clips resources already on a bin level, the verification state is escalated from the file resource to the library outline:
As multiple file resources can belong to a clips, a clip is inside a bin, and bins can be grouped in folders that can be ordered in the hierarchy inside the Library outline the following escalation is performed:
- File Resource verification state
- escalates to…
- Clip verification state
- escalates to…
- Bin verification state
- escalates to…
- Folder verification state
- escalates to…
- Library verification state
There’s a clear hierarchy of severity of states that overrule and therefore define the state of the level above:
- Defect
- overrules…
- Not Verified
- overrules…
- Verified
Understanding both cascades will help you already identify folders and bins containing problematic clips. Using the verification state column (see fig. 2) you can trace the problem down from the bin to the file resource that might be defect or not verified.
Folders only show the verification state when collapsed to avoid confusion with containing states.
Running Jobs for Bins
Due to their nature, the verification state icons on bin level do not necessarily give meaningful feedback while copy jobs are running for the bin (as running copy jobs naturally lead to a change of the verification state). This is the case because new file resources are registered and verification processes are on the run.
To address this a “Running Jobs” indicator has been introduced. Installed in the library on bin level, it shows in form of a little progress bar and tells the user that this bin currently has jobs running in the background:
Fig. 3: The Running Jobs indicator in the library outline
Furthermore, the “running jobs” indicator for bins also brings other benefits such as e.g. already seeing on bin level if no job is running anymore for a bin and a report can be created with a steady state of the library.
Migration
Please be aware that library versions of Silverstack prior to the 6.4 update do not include information about verification states. Therefore a migration to 6.4 will place verification states based on the existing job information. You can verify resources based on the existing hash information afterwards at any time.
Also PSLAs (Pomfort Silverstack Library Archives) exported with 6.3 and earlier do not include information about jobs or verification states. Opened with 6.4 or later all file resources will receive an “unverified” state.