One of the first things UploadSyntheticFilelist does is throw an exception if the volume is not in the Uploaded state. Or if it is in the Uploaded state, the next check would prevent a synthetic filelist from being created if the volume was not in the Uploading or Temporary states.
Removed the check for the volume not being in the Uploaded state as the warning in the second check handles that case.
Removed the using statement as it would dispose of the FilesetVolumeWriter after passing it to the UploadChannel. The UploadChannel could not use it since it had been disposed.
Fixed the GetRemoteVolumeFromIDAsync taking a fileset id and matching it up against a volume id. Now it will use fileset id to get the volume that matches the fileset.
Change the StopNow disruption test to not use a synthetic file list. The test was written with it not working and therefore fails a check on the number of filesets after stopping a backup.
Bonus fix for a possible null exception in Dispose for VolumeWriterBase.
When we modified the code in revision
68ffd86594 (pull request #4018) to
consider collections of IListResultFilesets instead of DateTimes, we
neglected to preserve the backup times in the logs.
This fixes#4109.
The list folder was not being written to dindex files when performing a
compact operation. After the data blocks have been moved to a new volume
and the new volume data is finished being written to the new index file,
read the blocklists from the database and write them to the new index
file.
Since we are keeping around a reference to the IndexVolumeWriter and
BlockVolumeWriter instances, we cannot wrap their usages in using
statements.
This fixes issue #4046.
The LocalDatabase class was deleting from the BlocklistHash table based on the volume id of blocks. The deletes for the Blockset and BlocksetEntry tables were using a union query which included the same query the BlocklistHash delete was using. Changed the BlocklistHash delete query to use the union as well to ensure that all three tables would use the same query to delete the necessary rows. This fixes the "Detected non-empty blocksets with no associated blocks!" error.
Moved a write call in the DataBlockProcessor to send a volume for upload after setting blockvolume to null. This prevents a null reference exception because otherwise it would be sent to the SpillCollector and it tries to add a block, but the volume has already been closed.
Added the ? operator to the RegistryUtility class to prevent a null reference exception while debugging. It was annoying catching it in the debugger.
Fixes#4037
The ID in the Fileset table is the auto-incremented integer. When
considering filesets for deletion (in particular, when deleting specific
versions), we need to reference the backup version number that is
exposed to the user (integers where the newest backup version is 0).
This extracts the logic for various fileset deletion strategies into
separate classes. This simplifies the code and makes it easier to test
the individual functionalities.
If the most recent backups were partials (and not followed by a full
backup), they should not be removed. A partial backup should only be
removed if it is followed by a full backup.
This concerns issue #3982.
We declare this to be a partial backup, with the presumption being that
a synthetic filelist is only created when a backup is interrupted.
This concerns issue #3982.
Previously, all filesets would be displayed as partial. Now, we obtain
the partial/full type from the fileset file (not the fileset.json) file
in the dlist file. If this file does not exist, the backup type
defaults fo full.
Note that this requires downloading and uncompressing the dlist file, so
performance of populating the restore list may be impacted
significantly.
This concerns issue #3982.
Previously, a yellow warning icon would be displayed but the logs did
not contain any details regarding the cause of the warning.
This concerns issue #3982.
According to the current implementation, the progress bar does not advance
when files are skipped by FilePreFilterProcess. This causes users'
confusion since the web frontend will get stuck at a certain stage for a
long time. This commit addresses this issue.
When support for parallel uploads was implemented, we overlooked a case
where a failed put of a dblock file is retried with a different
filename. In this case, an instance of TemporaryIndexVolume was created
in the DataBlockProcessor or SpillCollectorProcess prior to the
attempted put. The put would fail, and then retried with a different
filename. While the Remotevolume table in the database would reflect
the new filename, the TemporaryIndexVolume still contained a reference
to the old dblock filename. This would cause issues in direct restores,
etc., when the referenced dblock file could not be found.
Now, the TemporaryIndexVolume is only created after the dblock put has
completed.
This addresses issue #3932.
Kenneth Hsu