Release: 2.0.9.101 (Canary) 2024-06-27

Releases
21

I just spotted something while reverting my RPi-4 back to v2.0.8 that I noticed during the upgrade to v2.0.9 - after the upgrade I was forced to copy over the /etc/default/duplicati file from another machine as it was reverted to the default one. When I downgraded back to v2.0.8 it asked me what to do with the file:

Configuration file '/etc/default/duplicati'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** duplicati (Y/I/N/O/D/Z) [default=N] ?

I don’t think this happened during the upgrade which is why I lost the customised file.

22

I have registered a new issue for this.

It will write something to the commandline, such as:

Error detected: System.Net.WebException: The remote server returned an error: (404) Not Found.

If the commandline tool works but the UI gives 404, I would guess that they somehow use different URLs, which is strange because they both call the exact same code.

Unfortunately, there is no good way to pull out the update url from the UI. You can look in system settings and see if the property: UsingAlternateUpdateURLs : false is there, indicating that no override is detected.

Another way would be to abuse the Commandline feature and call the system-info command, as that will then be invoked in context of the running server, and will output the Autoupdate urls: property.

It should work, the code related to downloading the manifests has not been changed.

I just checked the codebase, and the button is now called “Download”. It might be a browser cache issue? You later post the screenshot that shows the “Download” button as a leftover from the canary build?

I have created an issue tracking the RPI 4 installation.

This sounds like a variation of “missing files”. Looking at the zip file contents the file is certainly there. In your previous screenshots, it also indicates that the file is present?

1 Like
23

The images are from two different Duplicati on the same system in a variety of drive folders.

You can sometimes see a bit of the black background around the 127.0.0.1 uses such as the controversial Install button, which can indeed be refreshed (hard refresh) to get a Download.

image

I had thought we had removed some caching issues, but maybe that only fixed static content.

C:\Duplicati\duplicati-2.0.9.100_canary_2024-05-30-win-x64-gui\Duplicati.GUI.TrayIcon.exe

is what this is, and FWIW it’s also the Duplicati where Quit got icon but left Duplicati running.

24

It does not fix the case where index.html is cached. I have added cache headers to the Kestrel update, so that part will be fixed soon.

I think this is fixed as part of the Kestrel update as well. At least I have not seen it happen since I started running with that version.

1 Like
25

I checked before killing it (it’s kind of in the way). It’s here:

26

Yep, it shows false for that.

It shows the same URLs as AutoUpdater check.

I’ll see if I can do WireShark with TLS decryption to see what’s happening under the hood…

27

I found the problem. In my main settings I have it set to the “Beta” channel, because that’s the one I usually prefer to be on. “Check for updates” on the Beta channel returns the 404 error. If I switch that to Canary the check works fine.

28

I don’t know if it matters, but I don’t Launch Duplicati at startup or Launch Duplicati now.

It seems very reproducible, but the damage level varies, or at least this one looks worse than last.

msiexec shows how to enable a bewildering variety of logging, but I wound up using /L*, and got

package.zip (99.4 KB)

where it seems to RemoveFiles, but not feel the need to InstallFiles to supply needed new version.

EDIT 1:

If I go along with the launch shortcut and launch at end, 2.0.8.1 launches, then I Quit that.
2.0.9.101 on top of that trips over its own install omission. The log file for this test ends in:

Action ended 11:21:51: ExecuteAction. Return value 1.
Action 11:21:51: ExitDialog. 
Action start 11:21:51: ExitDialog.
Action 11:21:51: ExitDialog. Dialog created
Action 11:22:06: LaunchApplication. 
Action start 11:22:06: LaunchApplication.
DEBUG: Error 2753:  The File 'Duplicati.GUI.TrayIcon.exe' is not marked for installation.

image

EDIT 2:

Going into a wild guess, I notice that the right-click → Properties → Details has some oddities:

image

The Product version used to be numeric. Now it’s not.

Why is Original filename field of the .exe talking about .dll? Inside .exe (via 7-Zip), version.txt:

FILEVERSION    2,0,9,101
PRODUCTVERSION 2,0,9,101
FILEFLAGSMASK  0x3F
FILEFLAGS      0x0
FILEOS         VOS_UNKNOWN | VOS__WINDOWS32
FILETYPE       VFT_APP
FILESUBTYPE    0x0
{
  BLOCK "VarFileInfo"
  {
    VALUE "Translation", 0x0, 1200
  }
  BLOCK "StringFileInfo"
  {
    BLOCK "000004b0"
    {
      VALUE "Comments",          "The Duplicati Tray implementation"
      VALUE "CompanyName",       "Duplicati.GUI.TrayIcon"
      VALUE "FileDescription",   "Duplicati.GUI.TrayIcon"
      VALUE "FileVersion",       "2.0.9.101"
      VALUE "InternalName",      "Duplicati.GUI.TrayIcon.dll"
      VALUE "LegalCopyright",    " "
      VALUE "OriginalFilename",  "Duplicati.GUI.TrayIcon.dll"
      VALUE "ProductName",       "Duplicati.GUI.TrayIcon"
      VALUE "ProductVersion",    "2.0.9.101-Canary-20240627+dab2b23332ee63b3bd98be99f807d69377413315"
      VALUE "Assembly Version",  "2.0.9.101"
    }
  }
}

EDIT 3:

I see InternalName also claims it’s a .dll. Here’s the view from 7-Zip where I got version.txt:

C:\Duplicati\duplicati-2.0.9.101_canary_2024-06-27-win-x64-gui\Duplicati.GUI.TrayIcon.exe.rsrc\

EDIT 4:

Running msiexec again let me do the usual Repair, which does some Copying new files. Log:

package.zip (60.0 KB)

29

Changing the subject, service install and uninstall are now quiet, both on screen and *InstallLog

C:\Program Files\Duplicati 2>Duplicati.WindowsService.exe install
Duplicati service installation succeeded.

C:\Program Files\Duplicati 2>Duplicati.WindowsService.exe uninstall
Duplicati service delete succeeded.

C:\Program Files\Duplicati 2>Duplicati.WindowsService.exe install
Duplicati service installation succeeded.

Files like these from the old code used to clobber the update. Now the old logs just sit there:

07/05/2024  10:12 AM             2,379 Duplicati.WindowsService.InstallLog
07/05/2024  10:12 AM             1,909 InstallUtil.InstallLog

Terminal view of 2.0.8.1:

C:\Program Files\Duplicati 2>Duplicati.WindowsService.exe install

Running a transacted installation.

Beginning the Install phase of the installation.
See the contents of the log file for the C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe assembly's progress.
The file is located at C:\Program Files\Duplicati 2\Duplicati.WindowsService.InstallLog.
Installing assembly 'C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe'.
Affected parameters are:
   logtoconsole =
   assemblypath = C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe
   logfile = C:\Program Files\Duplicati 2\Duplicati.WindowsService.InstallLog
   commandline =
Installing service Duplicati...
Service Duplicati has been successfully installed.
Creating EventLog source Duplicati in log Application...

The Install phase completed successfully, and the Commit phase is beginning.
See the contents of the log file for the C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe assembly's progress.
The file is located at C:\Program Files\Duplicati 2\Duplicati.WindowsService.InstallLog.
Committing assembly 'C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe'.
Affected parameters are:
   logtoconsole =
   assemblypath = C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe
   logfile = C:\Program Files\Duplicati 2\Duplicati.WindowsService.InstallLog
   commandline =

The Commit phase completed successfully.

The transacted install has completed.

C:\Program Files\Duplicati 2>Duplicati.WindowsService.exe uninstall


The uninstall is beginning.
See the contents of the log file for the C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe assembly's progress.
The file is located at C:\Program Files\Duplicati 2\Duplicati.WindowsService.InstallLog.
Uninstalling assembly 'C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe'.
Affected parameters are:
   logtoconsole =
   assemblypath = C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe
   logfile = C:\Program Files\Duplicati 2\Duplicati.WindowsService.InstallLog
Removing EventLog source Duplicati.
Service Duplicati is being removed from the system...
Service Duplicati was successfully removed from the system.

The uninstall has completed.

C:\Program Files\Duplicati 2>

2.0.8.1 seen above was far noisier, but I don’t recall if the terminal and log files were helpful.

30

Windows services GUI shows that 2.0.9.101 Description is missing. 2.0.8.1 used to say

Description:
Runs Duplicati as a service

in the left bar below Start the service. There is now nothing there, or in Description:

image
image722×62 4.97 KB

31

and now that I have Duplicati back on 2.0.9.101, I can repro the issue with drive root backup, however here I’m using a 100 MB VHD instead of my actual C:\ drive, that I prefer to backup:

image
image1067×492 41.8 KB

EDIT 1:

This is the same job that worked on 2.0.8.1. --snapshot-policy=On. I did use some exclude filters to keep Duplicati from going where it shouldn’t, derived from my actual C:\ drive backup, however 2.0.9.101 fails with or without them, basically emptying out new backup. Fortunately, versions before the problem were still around. I probably should have just deleted new version, however what I actually did was to run the job on 2.0.8.1 which probably just reattached blocks. Problem was that it took almost as long as an initial backup, which on this system is multi-days.

32

I think both of these differences are caused by the switch to .NET8.
The logic for building dll/exe is different, so I think it internally produces a dll with an entry point, and then renames the file when building it.

The version number is likely an artifact also of .NET8 having a different way of creating the file metadata.

Copyright can probably be added easily, I have added an issue for that.

I think this can be fixed as part of setting the assembly information as well.

Any specific way you are using it? Can you give me some steps that creates the problem on your end?

Like:

  • Install 2.0.8.1
  • Reboot
  • Install 2.0.9.101
  • Install is damaged

Also, thanks for the logs, I will dig into those.

I will track that as part of the VSS topic.

33

This was described quite a bit above, and latest test was similar to yours except for I didn’t reboot.

On another system, I already had 2.0.8.109 Debug installed and running. On this one, I rebooted first to be even cleaner than previous clean test. Verified no Duplicati processes, install 2.0.9.101, accept all defaults, peek with Terminal at damage, Launch Duplicati now. Fails as seen above.

EDIT 1:

Before verifying no Duplicati processes, I did have to Quit TrayIcon because it came up at login. Service did not come up at boot because I had it set to Manual start because 2.0.8.109 couldn’t uninstall it. This Windows was also Windows 10.

EDIT 2:

Pretty empty:

 Directory of C:\Program Files\Duplicati 2

07/06/2024  07:03 AM    <DIR>          .
07/06/2024  07:03 AM    <DIR>          ..
02/13/2024  09:38 PM               987 acknowledgements.txt
11/15/2022  06:42 AM           191,488 Artalk.Xmpp.dll
06/27/2024  11:43 AM            87,121 changelog.txt
02/13/2024  09:38 PM             5,720 default_compressed_extensions.txt
06/27/2024  11:43 AM            40,362 Duplicati.CommandLine.AutoUpdater.deps.json
06/27/2024  11:43 AM               357 Duplicati.CommandLine.AutoUpdater.runtimeconfig.json
06/27/2024  11:43 AM           152,066 Duplicati.CommandLine.BackendTester.deps.json
06/27/2024  11:43 AM               357 Duplicati.CommandLine.BackendTester.runtimeconfig.json
06/27/2024  11:43 AM           146,781 Duplicati.CommandLine.BackendTool.deps.json
06/27/2024  11:43 AM               357 Duplicati.CommandLine.BackendTool.runtimeconfig.json
06/27/2024  11:43 AM           186,104 Duplicati.CommandLine.ConfigurationImporter.deps.json
06/27/2024  11:43 AM               445 Duplicati.CommandLine.ConfigurationImporter.Implementation.runtimeconfig.json
06/27/2024  11:43 AM               445 Duplicati.CommandLine.ConfigurationImporter.runtimeconfig.json
06/27/2024  11:43 AM           158,683 Duplicati.CommandLine.deps.json
06/27/2024  11:43 AM           153,869 Duplicati.CommandLine.RecoveryTool.deps.json
06/27/2024  11:43 AM               357 Duplicati.CommandLine.RecoveryTool.runtimeconfig.json
06/27/2024  11:43 AM               357 Duplicati.CommandLine.runtimeconfig.json
06/27/2024  11:43 AM            37,182 Duplicati.CommandLine.SharpAESCrypt.deps.json
06/27/2024  11:44 AM            21,656 Duplicati.CommandLine.SharpAESCrypt.dll
06/27/2024  11:44 AM           160,408 Duplicati.CommandLine.SharpAESCrypt.exe
06/27/2024  11:43 AM               357 Duplicati.CommandLine.SharpAESCrypt.runtimeconfig.json
06/27/2024  11:43 AM            39,995 Duplicati.CommandLine.Snapshots.deps.json
06/27/2024  11:44 AM            21,656 Duplicati.CommandLine.Snapshots.dll
06/27/2024  11:44 AM           160,408 Duplicati.CommandLine.Snapshots.exe
06/27/2024  11:43 AM               357 Duplicati.CommandLine.Snapshots.runtimeconfig.json
06/27/2024  11:43 AM           202,880 Duplicati.GUI.TrayIcon.deps.json
06/27/2024  11:43 AM               445 Duplicati.GUI.TrayIcon.runtimeconfig.json
06/27/2024  11:43 AM           184,863 Duplicati.Server.deps.json
06/27/2024  11:43 AM               445 Duplicati.Server.runtimeconfig.json
06/27/2024  11:43 AM           185,818 Duplicati.Service.deps.json
06/27/2024  11:43 AM               445 Duplicati.Service.runtimeconfig.json
06/27/2024  11:43 AM            41,782 Duplicati.WindowsService.deps.json
06/27/2024  11:43 AM               357 Duplicati.WindowsService.runtimeconfig.json
04/07/2020  07:14 PM         1,303,040 e_sqlite3.dll
09/20/2023  06:11 PM         1,607,088 libHarfBuzzSharp.dll
01/10/2024  10:47 PM         9,414,064 libSkiaSharp.dll
07/06/2024  07:03 AM    <DIR>          licenses
05/17/2024  05:48 PM         1,337,360 mscordaccore_amd64_amd64_8.0.624.26715.dll
06/27/2024  12:00 PM                15 package_type_id.txt
02/13/2024  09:38 PM             1,637 SQLiteHelper.dll.config
03/26/2024  08:45 AM        10,058,752 storj_uplink.dll
05/20/2024  04:26 AM           813,328 System.Diagnostics.EventLog.Messages.dll
07/06/2024  07:03 AM    <DIR>          utility-scripts
07/06/2024  07:03 AM    <DIR>          webroot
              41 File(s)     26,720,194 bytes
               5 Dir(s)  15,846,416,384 bytes free

EDIT 3:

Previously I had fixed the missing files problem by doing Settings → Apps → Repair.
This time I ran the .msi again to do Repair. Seems OK, but I didn’t compare heavily.

EDIT 4:

I can also uninstall the service now. Maybe the earlier Debug version just had a bug?

34

I am following up on this one. Based on the trace and lintian output, I think the problem might be that the package is not requesting libc to be installed.

I saw that lintian complained that libc was not a dependency, but I assumed every system had it anyway. Now that I re-read the trace you got, it clearly says that package is missing.

Can you try:

> apt search libc6

If it is not installed, it should be fix-able with:

sudo apt install libc6

I will try to update the package to include the dependency, so it gets installed automatically.

35

Same problem, even with v2.0.9.102_canary_2024-08-02 upgrading from duplicati_2.0.8.1-1

I checked if libc6 was installed, and it was, tried to install it anyway, and still fails with the same messages

36

In case someone else is trying the same, the issue is that some libraries are built with a newer GLIBC than what RPI OS is using.
I have shared two binaries that are built with older GLIBC versions in this issue.