Since encryption (and compression) is detected after being encountered, the encryption module selection has been removed from the user interface when restoring.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@527 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
A restore now defaults to background and some filenames are also shown while restoring.
The "direct restore" option cannot run in the background as it requires the schedule to be stored in the database.
This can be fixed after version 2.0
git-svn-id: https://duplicati.googlecode.com/svn/trunk@525 59da171f-624f-0410-aa54-27559c288bec
Fixed a protential race condition with warning messages and file counts (cosmetic only) when using async transfers.
Spelling correction, Seperator -> Separator.
Changed so a restore operation can also supply advanced options.
Changed the format of timestamps in filenames to follow the Duplicity convention, which removes the need for --time-separator and --use-short-filenames.
Moved the URL utility into Core, to avoid compilation errors with Monodevelop.
Reorganized the runner to better support the LiveControls on all operations rather than only for backup/restore.
Update issue #210
Status: Fixed
I have now changed the time format to follow the Duplicity naming convention.
This means that all filenames are now generated with the time set as "yyyyMMddTHHmmssZ".
This format is more portable across all platforms, and easily sortable/readable.
The drawback is that the Z indicates UTC time, so if one looks at the filenames,
the times are not local. The motivation for this is to avoid trouble
with daylight savings time offsets.
There is full backwards compatibility as long as backups have not used more than
one character for --time-separator (only possible via commandline).
This new format means that the options --time-separator and --use-short-filenames
are now deprecated and removed from the user interface. It is possible to
access them from the advanced options page, along with the --use-old-filenames option.
If anyone needs these options for some reason, let me know, otherwise they will be removed
in a later version.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@523 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
I have now added an option called --exclude-empty-folders
It excludes folders AFTER the filter has been applied, so if the folder is left empty due to the filter, the folder is not included either.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@520 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
Added the first generic module, a password request module.
The motivation for this is to allow the creation of custom passphrase modules.
A simple model would be to add a GUI input dialog.
A more sophisticated version may read a passphrase to an encrypted file which contains the real passphrase or similar.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@519 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
After selecting a stored AWS ID for S3, the password is masked and cannot be revealed.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@518 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
It turns out that the fix to enable filters disabled the --file-to-restore option.
I have fixed that and also updated the restore output to correctly reflect what has happened during the restore.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@505 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
I have now implemented a password protection control.
You can now only view passwords when you enter them.
After this, you may reset the passwords, by entering a
new one, but you cannot read the existing passwords.
To protect against people reading the database,
which contains the passwords in clear text, the
database is now encrypted by using the standard
SQLite encryption method. This is different
than what I proposed, but is a much stronger
protection than merely scrambling the passwords,
and also protects all information (servername, etc).
It works by setting an environment variable
called DUPLICATI_DB_KEY. When no password
is set, Duplicati will use the key "Duplicati_Key_42",
ensuring that all databases are encrypted by default.
Using a pre-defined publicly known key is obviously
not a strong protection, but it protects from casual
users attempting to browse the database, and it also
protects from string scanners that scan a harddisk
for possible passwords.
On the first startup, Duplicati will encrypt the database,
using the mentioned key. You may want to delete any backup
databases that are placed in the same folder as the database.
Should you wish to decrypt the database, you can start
Duplicati.exe with the commandline option "--unencrypted-database".
This will use the current key to decrypt the database, and save it
without encryption.
Should you wish to change the database password, simply decrypt the
database, then change the password via the environment variable,
and start Duplicati.exe as normal.
The SQLite documentation for the feature is here:
http://www.hwaci.com/sw/sqlite/see.html
Unfortunately, it does not seem as if any
of the free SQLite tools supports this.
The SQLite library found on Ubuntu
does not support encryption, so I have disabled
this feature by default on Linux.
If a user has a special compiled version
of SQLite, they may use the environment
variables as mentioned above.
I will write this information into a wiki
page as soon asap.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@498 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
The backup can now proceed with a broken signature file.
A restore operation is not affected by broken signature files either,
although the restore will include previously deleted files,
if the signatures are damaged.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@492 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
The code to support this was already in place, but did
not work because Application.Exit() had been invoked,
making all messageboxes return Cancel without showing.
I also improved the logic a bit so a cancel does
not invoke the cleanup afterwards, making the exit
procedure faster.
I also added checks for the stop command to the
code that fetches the signature files, to make
the application respond faster to the stop command.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@490 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
I have now fixed it so the UI sets the required option automatically.
I also fixed a minor typo "sfpt" -> "sftp".
git-svn-id: https://duplicati.googlecode.com/svn/trunk@486 59da171f-624f-0410-aa54-27559c288bec
in the local format (eg. using backslash). This could
create trouble if the backup was made on windows and restored
on linux.
Update issue #229
Status: Fixed
I have updated the code to store the correct time for the
files, as well as the folders. The folder timestamp
adds a slight overhead to the volumes, as Zip
archives have no folder entries, so the timestamps
for folders are kept in a separate file.
The time stored in the existing archives is the date the backup
was made, not the last modified time, so it is not possible to
restore the modification date for existing archives.
When restoring new archives, the correct date is set
for both files and folders.
When restoring older archives, the backup date is used
for files, and nothing is done for folders.
I also changed the internal storage to use UTC time format
for all timestamps to avoid problems with backup/restores on
machines with different timezones.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@484 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
I have fixed a number of UI issues when using async uploads.
For one, the pause/stop features now work.
If the progress is paused, a upload progressbar will be displayed,
so the progress does not appear to hang.
When the backup is complete, the remaining uploads
are now done as normal, resulting in a normal UI display with progress.
I have also reserved some space on the progress bar for cleanup,
and inserted a status message indicating that the cleanup is in progress.
The async now works so well, that I think it should be on by default.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@482 59da171f-624f-0410-aa54-27559c288bec
The purpose of this change is to prevent loading a defunct MD4 implementation,
which exists in the Mono library in all versions prior to this path (july 2010):
http://github.com/mono/mono/commit/6be3c20a61d4c9937d4b9f1e95783a6203f9f9c7
The drawback is that IF the system has a native MD4 library, it is not used.
That is of course a negative thing, but so far I have not seen any stock
windows/linux system with native MD4 support.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@481 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
After a lot of work, I have now re-written the entire SharpRSync library.
My tests indicate that generating a diff file for an 8gb file took 10 minutes before, and now takes 8 minutes.
A delta for the same (unchanged) 8GB file took 58 minutes, and now takes 7 minutes.
The implementation seems to run faster under 64 bit, but I'm unsure if it is
related to the actual instructions issued, or the address simulation/conversion done by the OS.
I have also greatly optimized the amount of memory required by the program.
On windows, a delta for an 8GB file can be now be created with a total of 125 mb required memory.
The base app takes 65mb, so the used memory is around 60mb, and the raw diff file is approximately 44mb.
I compared it a bit to the rdiff program on linux.
For a 150mb file, rdiff takes about 1 second to generate a diff, and the same for a delta.
SharpRSync runs the same in about 7 seconds, although some of that is the mono startup and library loading.
For a 8gb file rdiff can generate a diff in about 500 seconds, where SharpRSync takes about 590 seconds.
When generating a delta, rdiff uses 530 seconds, and SharpRSync uses 770 seconds.
The last measurement is inaccurate as the memory requirement under mono is greater, and the test machine
had low memory, so there was a lot of swapping going on.
An interesting side effect is that the rdiff generated delta file is about 380kb, where the SharpRSync delta is 15 bytes.
This is because rdiff does not do the sequence matching optimization mentioned on the librsync page (last paragraph):
http://rsync.samba.org/tech_report/node4.html
Further optimization should probably focus on getting the MD4 algorithm to run faster.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@480 59da171f-624f-0410-aa54-27559c288bec
Also modified the help text for the async folder location to clarify that it also works for synchronous uploads.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@478 59da171f-624f-0410-aa54-27559c288bec
Now also cleans the backup manifest.
This bug means that the after a delete-older-than or delete-all-but-n-full would leave the backup manifest.
Issuing the same command again would then remove the manifests.
This should not be noticeable by regular users, except that the lingering manifests may be displayed when attempting a restore operation.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@477 59da171f-624f-0410-aa54-27559c288bec
Also fixed a bug with the "allow-full-removal" option.
Update issue 110
I have now added a limit to the number of generated volumes, and as described, it is 2 by default.
I have also added support for setting a custom folder where the volumes are placed in. They are placed in the temp folder by default.
I re-read the comments on this issue, and I can see that I misread the statements from Baris.Eris.
This limit does not prevent any volumes from being uploaded (you can use the --totalsize option for that),
it just pauses the volume generation when there are already two or more volumes waiting to be uploaded.
As soon as a volume is uploaded, the program continues. The purpose of this is not to limit the data being
uploaded, but rather to prevent spamming the disk with hundreds of volumes.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@476 59da171f-624f-0410-aa54-27559c288bec
Added snapshot support using either VSS (win xp/vista/7) or LVM (linux).
Using the snapshot feature requires administrative/root privileges, and is toggled by the "snapshot-policy" option (by commandline or in advanced settings).
Also improved the validation of options to not show incorrect warnings.
This fixes issue #233.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@461 59da171f-624f-0410-aa54-27559c288bec
Also fixed a problem with detecting the right OS version,
this should only cause you trouble if you have files with the same name but different casing.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@453 59da171f-624f-0410-aa54-27559c288bec
Fixed issue #215.
If the user chooses EU buckets, bucketnames that are not valid hostname labels will be rejected.
If the user does not choose EU buckets, a warning is displayed for bucketnames that are not valid hostname labels, and the setup is switched to the path-style calling method.
Fixed issue #214.
There were multiple issues with entering a bucket/folder type path, those should now be resolved.
Fixed issue #212.
The UI and commandline now supports Reduced Redundancy Storage.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@430 59da171f-624f-0410-aa54-27559c288bec
This was based on the idea that the interfaces should remain static.
I hope this change is enough to ensure stable interfaces until release 1.2.
Overview of changes:
Moved all interfaces into the same dll.
Encryption and compression is now plugable modules, just as the backends.
Encryption/compression can now register an UI.
Encryption now uses AESCrypt as a default.
GPG does not default to using the --armor option.
Added support for generic modules, but none are written yet.
Added support for plugable settings pages in the "Options" dialog.
Fixed issue #148.
Duplicati now uses AESCrypt as the default encryption format.
Fixed issue #199.
GPG now supports custom commandline options.
Fixed issue #207.
Encryption modules are now plugable.
Fixed issue #118.
S3 credentials are now stored.
Fixed issue #151.
Backends can now register system wide options.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@427 59da171f-624f-0410-aa54-27559c288bec
