When the file list is over 4GB one needs to have the zip64 option
enabled. This commit catches the exception and reports it as an error so
that the user knows what the problem is.
Fixes duplicati/duplicati#/4206
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.
This fixes a regression introduced around revisions e0899a2a91 ("add
method to add the filelist file") and 3b5af1cf01 ("add method to add
filelist file"), where the filelist was not written by all usages of the
FilesetVolumeWriter. Previously, one would have to invoke
AddFilelistFile with each usage. Now, we simply do so when the
FilesetVolumeWriter is closed.
We also modified the UploadSyntheticFilelist so that the usage of the
FilesetVolumeWriter is contained in a using statement, which will ensure
that it is disposed.
This fixes issue #3924.
This reverts a change made in revision 31ac40083a ("Prevent temp files
in VolumeWriterBase from being deleted prematurely" in pull request #2637).
It's unclear what issue was being worked around by preventing the
removal of the temporary files (based on comments in pull request #2637,
it appears to be related to tests that failed only on Travis). However,
this workaround prevented the removal of temporary files created during
compact operations, which caused several users' temporary directories to
be filled up with files that should have been removed.
This concerns issue #3652.
This ensures the removal of the temporary file containing the
filelist.json that remained regardless if files needed to be uploaded or
not.
This concerns issue #3652.
Changed a few things on the way, removing the log process
# Conflicts:
# Duplicati/Library/Main/Controller.cs
# Duplicati/Library/Main/Database/ExtensionMethods.cs
# Duplicati/Library/Main/Database/LocalBackupDatabase.cs
# Duplicati/Library/Main/Duplicati.Library.Main.csproj
# Duplicati/Library/Main/Operation/BackupHandler.cs
# Duplicati/Library/Main/Operation/FilelistProcessor.cs
# Duplicati/Library/Main/Operation/PurgeBrokenFilesHandler.cs
# Duplicati/Library/Main/Operation/TestFilterHandler.cs
# Duplicati/Library/Main/Options.cs
# Duplicati/Library/Main/ResultClasses.cs
# Duplicati/UnitTest/BasicSetupHelper.cs
While this does not affect any behavior, it more accurately describes
the accessibility. Since abstract classes can only be instantiated by
an instance of a derived type, the constructors should at most have
protected access.
InvariantCulture is useful when comparing / sorting human language strings in a culturely correct way. It handles things like accented letters in a way that makes sense to humans (e.g., 'a' should be sorted next to 'á', rather than after 'z').
Ordinal looks just at the raw code points of the characters. As such, it is recommended for use in cases when comparing system strings (file paths, command line parameters, config settings, etc.). Since it doesn't need to use the culture specific sorting rules, this method can often be faster.
For more information, see https://stackoverflow.com/questions/492799/difference-between-invariantculture-and-ordinal-string-comparison (and other related questions)
Kenneth Skovhede