Release: 2.0.4.5 (beta) 2018-11-28

[JonMikelV]

@stahr

Can I delete the “backup YYYYMMDDHHMMSS.sqlite” files if I don’t intend to go back to 2.0.3.3?

Yes, those are safe to delete.

And yes, I think we need to inform users they are being created as they can take up quite a bit of space.

[curtis]

I’m experiencing a couple of issues with Duplicati - 2.0.4.5_beta_2018-11-28. The first is cosmetic. Previously the UI would display how long the last successful session took to complete. After the update that information is no longer presented. (See attached photo)

The second issue has to do with ERRORS after a backup session. I get two (2) similar errors on nearly every backup, although the backup successfully completes. The errors look like this:

Errors: [
        2018-12-18 06:18:15 -05 - [Error-Duplicati.Library.Main.Database.LocalBackupDatabase-CheckingErrorsForIssue1400]: Checking errors, related to #1400. Unexpected result count: 0, expected 1, hash: 24eFFzeHvBWhDRzT2+1LyIRFewnDo8EoKmvp4s95hgQ=, size: 88464, blocksetid: 142641, ix: 173, fullhash: cmulyvu4QvHCSDj21c+7G/ov8D0ncdod59yVONl3ReY=, fullsize: 17803664,
        2018-12-18 06:18:15 -05 - [Error-Duplicati.Library.Main.Database.LocalBackupDatabase-FoundIssue1400Error]: Found block with ID 621173 and hash 24eFFzeHvBWhDRzT2+1LyIRFewnDo8EoKmvp4s95hgQ= and size 63840
    ]

Ideally I’d like for everything to run clean…successful, with no warnings, no errors. I’d like to get some insight on what’s going on with these errors. Any help you can provide is appreciated.

I’m running Duplicati on a MacBookAir with the latest version of macOS Mojave. I use Homebrew to install/update Duplicati’s dependancies.

[pesch]

Hello,

I just updated from
duplicati-2.0.2.1_beta_2017-08-01-x64.msi
->
duplicati-2.0.4.5_beta_2018-11-28-x64.msi

and I can’t start the duplicti application anymore.
All I see is the process popup twice in taskmanager. Then its gone.

this is the crash-log: C:\ProgramData\Duplicati\updates\Duplicati-crashlog.txt

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Could not load file or assembly 'CoCoL, Version=1.5.0.24305, Culture=neutral, PublicKeyToken=0983de3c914beeaa' or one of its dependencies. The system cannot find the file specified.
   at Duplicati.GUI.TrayIcon.HostedInstanceKeeper..ctor(String[] args)
   at Duplicati.GUI.TrayIcon.Program.RealMain(String[] _args)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Duplicati.Library.AutoUpdater.UpdaterManager.RunMethod(MethodInfo method, String[] args)

Any ideas?

[pesch]

I run the setup again. Choose Repair. Apparently the tray gui starts now.
The setup routine must have some strange problems on updates…

Let’s hope it will be doing the backups as it is supposed to do

[JonMikelV]

@pesch

Could not load file or assembly 'CoCoL

Hello @pesch, welcome to the forum!

It sounds like you’re seeing the same thing I did here where an re-install (not an in-app-update) seemed to resolve the issue.

Duplicati 2.0.2.9 won’t start

Sorry, Tuesday’s uninstall then reinstall (of 2.0.2.9) resolved the issue. But when it wasn’t working I could find no CoCoL.dll in either the Program Files or Windows trees. My assumption was that a failed (something in use, reboot requires) in-app upgrade from 2.0.2.8 to 2.0.2.9 had gotten as far a removing old version files but not installing the new versions. I assume it doesn’t do any good to give you the DLL version on the working copy…

[pesch]

Hi JonMikeIV,

thanks. I tried that, after I saw a similar post.
The in-app update does not work at all. I downloaded the installer and run it manually.

It looks like everything is fine now.

[JonMikelV]

@pesch

It looks like everything is fine now.

Glad to hear that worked for you!

@pesch

The in-app update does not work at all.

Yes - the in-app updater seems to have broken with a recent release. We still haven’t identified / fixed the cause so until then manual installs (which will update your “base” version) or manual updates (unzipping the new version into the updates folder) will be necessary.

[ts678]

For Windows users who have done the extra manual commandline work to run Duplicati as a Windows service, there are probably two default steps done for Tray Icon in the .msi install that you should change. Details here.

[sjl1986]

So far, I’ve updated two machines. I was able to download and install via the GUI. Then I clicked activate and it appeared nothing happened. So, I restarted the service, then refreshed the GUI, and it showed the updated version was installed. It’s easier than a manual install.

[unique]

It appears that every backup set I setup using 2.0.4.5 beta running on macOS 10.13.6 do creates very long filenames of sqlite db.

Backups created in previous versions:
-rw------- 1 root wheel 1615063040 4 Jan 23:37 QAMITZPQQT.sqlite
-rw------- 1 root wheel 366998528 23 Nov 04:08 WEUUNULDGT.sqlite

created with 2.0.4.5_beta_2018-11-28
-rw------- 1 root wheel 2087827456 6 Jan 09:26 73809065877676817180.sqlite
-rw------- 1 root wheel 1240110080 6 Jan 09:33 83657969896684868069.sqlite
-rw------- 1 root wheel 513878016 5 Jan 07:20 86838871726786817187.sqlite

Is this OK by design or should I worry?

[JonMikelV]

@unique

every backup set I setup using 2.0.4.5 beta running on macOS 10.13.6 do creates very long filenames of sqlite db.

Heh - I asked the same thing. As far as I can tell it’s supposed to be this way, but I don’t know why it as changed.

Sqlite database names

This isn’t a help request - I’m just curious about a change. I noticed recently (around 2.0.4.x releases) that new job databases seem to be all numeric (such as 89677133708265797163.sqlite) where they used to be alpha based (such as CTPKXALMSD.sqlite). The “global” database file is still Duplicati-server.sqlite and backups (usually created as part of a Repair or Recreate) are still timestamped (such as backup 20190106091829.sqlite). What’s the reasoning behind the naming change?