Status: Fixed
Turns out it was a more generic problem than I first assumed.
The problem was that there are two similar controls on the page (the duration editors),
and their internal controls are named the same, so it applied the setting from the top control to the lower,
and the top control was set to "each day".
The other problem "system is slow" is also fixed, although I'm unsure why it happened in the first place.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@630 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
There is now a Tahoe-LAFS backend option.
It is quite new, so obviously it is fairly untested in real life.
It passes all unittests, and is largely based on the WEBDAV backend which as seen some action.
I will put up a preview build with Tahoe-LAFS support soon.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@623 59da171f-624f-0410-aa54-27559c288bec
I have now added preliminary support for keyfiles under SSH.
For the time being it only supports OpenSSH private key files, and only unencrypted or tripple-DES encrypted ones.
This is a limitation of the SharpSSH library, which is based on an old JSCH implementation with this limitation.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@622 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
Hmm.. If I do that, I get an english language page.
I have removed the "lc=DK" from the URL, which seems to be the language indicator.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@612 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
I found the error in the USN handling code.
The problem was that the filename was compared case insensitive, when doing USN file listing.
This caused all my tests to pass (as the folders have the correct case).
I managed to type it with the incorrect case in a test setup and found the error.
I will put up a new preview soon with the fix.
I would recommend that you use that version instead and delete the usn-policy setting from the backup.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@605 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
Yes, nicely spotted, thanks for reporting.
It seems that the settings was actually saved and applied,
but just didn't show up, so a re-save would clear it.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@594 59da171f-624f-0410-aa54-27559c288bec
I certainly don't mind fixing minor issues.
Spelling errors have a tendency to make the product look
incomplete, so I appreciate spelling error reports.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@590 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
Status: Fixed
USN is now activated by default on windows, but requires Administrative privileges.
If it fails to activate, it is silently ignored, and normal filesystem enumeration is used.
Set --usn-policy to:
"on" to get a warning if it fails,
"required" to abort the backup if it fails
"off" to disable USN
"auto" to silently ignore a fail
git-svn-id: https://duplicati.googlecode.com/svn/trunk@584 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
I have now added a check to ensure that the string is less than 64 characters.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@582 59da171f-624f-0410-aa54-27559c288bec
I have updated the app.config file to include the useLegacyV2RuntimeActivationPolicy="true" attribute, and I can open and run it directly from VS2010 (after upgrade wizard),
and it seems to retain the attribute, and not cause trouble for 2.0.
If someone wants to produce a installer from a VS2010 build, beware that the build script uses a custom app.config file which will overwrite this one.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@575 59da171f-624f-0410-aa54-27559c288bec
Added the --vss-exclude-writers option.
Update issue #260
Status: Fixed
I have now added a --vss-exclude-writers commandline option.
I had another look at the other supported options, and I consider this the most important.
I made the simplest possible version, so it only supports class guids, not component names
or writer instance ids.
If you need any of the other switches or the component names, please let me know.
I would also be interested in hearing that it actually works (I get no errors, but thats no proof).
You can specify multiple writers with a semicolon: --vss-exclude-writers="{d61d61c8-d73a-4eee-8cdd-f6f9786b7124};{0bada1de-01a9-4625-8278-69e735f39dd2}"
If you need the guids, you can get them with the following command in a command prompt:
vssadmin list writers
git-svn-id: https://duplicati.googlecode.com/svn/trunk@574 59da171f-624f-0410-aa54-27559c288bec
Also fixed a bug where the suggested target path shown in the tree was not used, rather the previous \0 and \1 style was used.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@573 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
The logic was attempting to prevent a case where the backup was scheduled to run and "Run backup now" was checked.
In this special case, the "Run backup now" does nothing because the backup will run twice otherwise.
The logic was a bit flawed, so based on some various settings it would detect that it was scheduled to run,
while it was not.
Thanks to your fine description, I was able to reproduce easily and fix it.
With the regards to the other error message, I have reproduced it by doing the following without restarting:
1) create the backup
2) edit the backup
3) delete the backup
I will create a new issue for it, but the bug is deep in the database abstraction layer,
so it is pretty hard to debug.
Update issue #227
Status: Fixed
Now correctly removes the deleted task from the scheduler and updates the display.
I also managed to get a slight speedup on the display update.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@572 59da171f-624f-0410-aa54-27559c288bec
After a fix with source folder filters, the internal file "added_folders.txt"
contains the root folder entry, but not suffixed with a slash/backslash,
which caused an "index of of bounds" error when attempting to restore.
Update issue #295
Status: Fixed
I found 3 situations where an opened file was not closed.
Strange thing is that it should have been that way since the multivolume stuff was introduced.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@569 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
It turns out that the "autocheck" feature was also broken because of the sorting.
Now the sorting works for all columns, and the text and autocheck follows the item.
I also added a feature where boolean columns get the value "true" inserted if the checkbox is clicked.
The grid is now sorted by the option name.
I experimented a little with the sorting, and if the "Enabled" column is sorted, things tend to flip around
when checking/unchecking items, so I discarded that idea, and went with sorted by "Name" only.
If desired, the user can sort by clicking the "Enabled" column.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@566 59da171f-624f-0410-aa54-27559c288bec
The only difference between x64 and x86 is the default install folder.
For some reason the x86 version of the MSI prevents the user from installing to regular "Program Files" on x64 systems.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@563 59da171f-624f-0410-aa54-27559c288bec
Status: Fixed
I found out that Mono on windows does not support "mixed-mode" assemblies, which is what the System.Data.SQLite.dll's are:
http://www.mono-project.com/CPlusPlus
On my machine it gives a weird error with "CRT not initialized" if I run Duplicati under Mono.
I have changed the loader to check for Linux AND Mono.
I have also update the build script to include the version of the dll that you found,
it seems that Mono only runs with 32bit on windows, so the dll must also be 32 bit.
git-svn-id: https://duplicati.googlecode.com/svn/trunk@562 59da171f-624f-0410-aa54-27559c288bec
