Status: Fixed
Changed to the AWSSDK library, which fixes a few quirks, but basically seems to be the Affirma version slightly renamed.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@811 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
Thanks to Livio, this is now fixed and can be toggled with the --allow-sleep command.
It will be included in the next preview release.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@807 59da171f-624f-0410-aa54-27559c288bec
The code should now "gracefully" handle missing timestamps.
For files with no modification time, they are assigned 1. jan. 1970 00:00:00 (EPOCH).
This has the drawback that files are read fully because we cannot rely on the modification timestamp, so it may be a bit slower.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@802 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
The folder list is now case-insensitive on Windows,
so the problem no longer arises.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@750 59da171f-624f-0410-aa54-27559c288bec
Now also stores the filename+size of signature/content files to ensure that the parsed filenames match the expected ones.
The filesize and filenames are used to verify that the remote file is complete, without downloading it.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@716 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
I have now added a module called http-options which can be used to
configure http options, notably the 100-Expect.
I am unsure if it will break existing installations if I disable
it by default, so it is still enabled but can be disabled by the
switch --disable-expect100-continue.
You can set this option in the GUI under "Advanced options".
git-svn-id: https://duplicati.googlecode.com/svn/trunk@713 59da171f-624f-0410-aa54-27559c288bec
This commit includes an option to create an unencrypted verification file.
There is now a check to see if all volumes mentioned in the manifest exists,
before performing backup/restore operations.
This check is also performed on cleanup.
There is now a check that prevents auto-cleanup from removing more than
2 orphan files.
If a delete-older-than or delete-all-but-n-full is interrupted, the leftover
files will not be auto-deleted but must be deleted with the cleanup command,
which allows the user to see what files are delete.
Update issue #360
Status: Fixed
There is now a complete verification chain, where the manifest hashes are verified backwards.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@711 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
I found and fixed the issue, I was using an int instead of a long for the filesize,
which caused it to truncate.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@683 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
That is an incorrect warning, the priority is applied despite the warning.
I have fixed the code so the warning does not appear anymore.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@675 59da171f-624f-0410-aa54-27559c288bec
Changed the non-streaming file-backend interface to use sytem copy calls rather than
manual stream copy.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@654 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
Now allows 1% (max 1 hour) slack in the time difference.
Can be disabled with the --disable-time-tolerance flag.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@595 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
The implementation is a mix of the the three mentioned methods (issue #247).
There is a commandline option called --open-file-policy, which can be set to
"ignore", "snapshot" or "copy".
The "ignore" setting does the same as previous version, simply exclude the file from the
backup set.
If the setting is either "snapshot" or "copy", and the file it locked, it is opened in non-excusive read mode.
Once open, a in-memory signature file is generated. This is compared to the previous signature to detect changes,
just as the normal operation. If the file has not changed, the file is skipped as it would normally be.
If the file has changed and the policy is "snapshot", the file will be processed as normal,
but during the file read, a new signature is generated. This new signature is stored
in the signature archives. When writing the new signature, it is compared to the original signature.
If the file has changed during the backup operation, a warning is written to the output log.
If the policy was set to "copy", the modified file is copied to a temporary location,
while a new signature is generated. If the copy fails due to a file change, the file
is omitted from the backup set. If the copy succeeds, the file is known to not have changed
during the first access and the copy, which gives some assurance that the file is not
actively being written, at the expense of a copy operation.
The default setting is "snapshot", because this is likely to work in most scenarios,
and potentially produces a broken file rather than guarantee a missing file (by "ignore").
Note that when reading an open file, there is always a chance that the file is being written,
so you may end up with a broken file in the backup. This is also true for the VSS and LVM snapshots,
except for VSS-aware applications.
The "copy" method is meant to minimize this risk, but there is no guarantee that the file is in an
acceptable state, just because it has not been written for any period.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@588 59da171f-624f-0410-aa54-27559c288bec
