Could someone help me?
I’m on Windows version 2.0.7.1, the console indicates upgrade to 2.1.0.2, I order the upgrade to run but it doesn’t finish.
I read that the automatic update is not done in this case, but I couldn’t find the right way to do it.
How can I update?
Thanks
This likely needs developer help. I suspect there’s a problem with how the build is offered.
There’s also a concern about 2.1.0.3 Beta (which I think has bugs that caused 2.1.0.5 fix).
Regardless, current Beta offer is 2.1.0.2, but does your About → Show log show the error:
System.Exception: Unable to verify unpacked folder for url: https://alt.updates.duplicati.com/beta/duplicati-2.0.8.1_beta_2024-05-07.zip
at Duplicati.Library.AutoUpdater.UpdaterManager.DownloadAndUnpackUpdate(UpdateInfo version, Action`1 progress)
I suspect the reason for 2.0.8.1 is https://updates.duplicati.com/beta/latest.manifest asking for
"CompressedSize":50604805,"UncompressedSize":133581950,"SHA256":"UW2Dp4Ej+HaoXgEtit/Msx53za+b+F1SfOMLVUEJRnU=","MD5":"s+BuWLxel7uPWWPpjDNYQQ==","RemoteURLS":["https://updates.duplicati.com/beta/duplicati-2.0.8.1_beta_2024-05-07.zip","https://alt.updates.duplicati.com/beta/duplicati-2.0.8.1_beta_2024-05-07.zip"]
What it does for me when I ask it to Install looked a lot like the old update method, which 2.1.0.2 won’t do – but I think it grabbed 2.0.8.1. Watching its file details, its changelog.txt is 2.0.8.1 size.
I think the right way to do it might be broken, but if it worked, you’d likely get an .msi to install.
v2.1.0.2_beta_2024-11-29 is the download page, and you might want duplicati-2.1.0.2_beta_2024-11-29-win-x64-gui.msi for typical Windows system and use.
EDIT 1:
The manifest with 2.0.8.1 at the bottom has 2.1.0.2 at the top, maybe explaining 2.1.0.2 popup.
Canary manifest has 2.0.9.109 at the top and 2.0.7.103 at the bottom. I haven’t tested it further.
EDIT 2:
Fixed Canary manifest typo done above. Noticed that while testing the CLI autoupdate.
C:\Duplicati\duplicati-2.0.7.2_canary_2023-05-25>Duplicati.Library.AutoUpdater install
Downloading update "Duplicati v2.0.9.109" ...
Downloading 5% ...
Downloading 10% ...
Downloading 15% ...
Downloading 20% ...
Downloading 25% ...
Downloading 30% ...
Downloading 35% ...
Downloading 40% ...
Downloading 45% ...
Downloading 50% ...
Downloading 55% ...
Downloading 60% ...
Downloading 65% ...
Downloading 70% ...
Downloading 75% ...
Downloading 80% ...
Downloading 85% ...
Downloading 90% ...
Downloading 95% ...
Downloading 100% ...
Error detected: System.Exception: The found version was not the expected version
at Duplicati.Library.AutoUpdater.UpdaterManager.VerifyUnpackedFolder(String folder, UpdateInfo version)
Error detected: System.Exception: Unable to verify unpacked folder for url: https://updates.duplicati.com/canary/duplicati-2.0.7.103_canary_2024-04-19.zip
at Duplicati.Library.AutoUpdater.UpdaterManager.DownloadAndUnpackUpdate(UpdateInfo version, Action`1 progress)
Downloading 0% ...
Downloading 5% ...
Downloading 10% ...
Downloading 15% ...
Downloading 20% ...
Downloading 25% ...
Downloading 30% ...
Downloading 35% ...
Downloading 40% ...
Downloading 45% ...
Downloading 50% ...
Downloading 55% ...
Downloading 60% ...
Downloading 65% ...
Downloading 70% ...
Downloading 75% ...
Downloading 80% ...
Downloading 85% ...
Downloading 90% ...
Downloading 95% ...
Downloading 100% ...
Error detected: System.Exception: The found version was not the expected version
at Duplicati.Library.AutoUpdater.UpdaterManager.VerifyUnpackedFolder(String folder, UpdateInfo version)
Error detected: System.Exception: Unable to verify unpacked folder for url: https://alt.updates.duplicati.com/canary/duplicati-2.0.7.103_canary_2024-04-19.zip
at Duplicati.Library.AutoUpdater.UpdaterManager.DownloadAndUnpackUpdate(UpdateInfo version, Action`1 progress)
New version "Duplicati v2.0.9.109" installed!
C:\Duplicati\duplicati-2.0.7.2_canary_2023-05-25>
This is reminiscent of the 2.0.7.1 Beta GUI behavior (with files watched with Process Monitor).
GUI shows it downloading and verifying as old autoupdate does, but nothing actually gets left.
Let me explain better. When I click on update, I receive these Logs:
- 6 de Mar de 2025 às 09:07: Error in updater
System.Exception: The found version was not the expected version em Duplicati.Library.AutoUpdater.UpdaterManager.VerifyUnpackedFolder(String folder, UpdateInfo version)
- 6 de Mar de 2025 às 09:07: Error in updater
System.Exception: Unable to verify unpacked folder for url: https://alt.updates.duplicati.com/beta/duplicati-2.0.8.1_beta_2024-05-07.zip em Duplicati.Library.AutoUpdater.UpdaterManager.DownloadAndUnpackUpdate(UpdateInfo version, Action`1 progress)
- 6 de Mar de 2025 às 09:06: Error in updater
System.Exception: The found version was not the expected version em Duplicati.Library.AutoUpdater.UpdaterManager.VerifyUnpackedFolder(String folder, UpdateInfo version)
- 6 de Mar de 2025 às 09:06: Error in updater
System.Exception: Unable to verify unpacked folder for url: https://updates.duplicati.com/beta/duplicati-2.0.8.1_beta_2024-05-07.zip em Duplicati.Library.AutoUpdater.UpdaterManager.DownloadAndUnpackUpdate(UpdateInfo version, Action`1 progress)
still, clicking on LIVE:
Mar 6, 2025 at 9:06 AM: Failed to load assembly c:\Program Files\Duplicati 2\updates\2.0.7.1\Xamarin.Mac.dll, error message: Non-abstract, non-.cctor method in an interface.
{“ClassName”:“System.TypeLoadException”,“Message”:“Método non-abstract, non-.cctor em uma interface.”,“Data”:null,“InnerException”:null,“HelpURL”:null,“StackTraceString”:" em System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes)\r\n em System.Reflection.RuntimeAssembly.GetExportedTypes()\r\n em Duplicati.Library.DynamicLoader.DynamicLoader`1.FindInterfaceImplementors(String additionalfolders)",“RemoteStackTraceString”:null,“RemoteStackIndex”:0,“ExceptionMethod”:“8\nGetExportedTypes\nmscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\nSystem.Reflection.RuntimeAssembly\nVoid GetExportedTypes(System.Reflection.RuntimeAssembly, System.Runtime.CompilerServices.ObjectHandleOnStack)”,“HResult”:-2146233054,“Source”:“mscorlib”,“WatsonBuckets”:null,“TypeLoadClassName”:“CallKit.ICXCallObserverDelegate”,“TypeLoadAssemblyName”:“Xamarin.Mac, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065”,“TypeLoadMessageArg”:null,“TypeLoadResourceID”:8208}
Thank you for reporting the other three. I see them too.
We seem to be seeing the same problem with directions on the update server being incorrect.
It’s pointing to the wrong Duplicati. Need the developer.
As a side question, what channel do you prefer? Stable now also exists, with a newer release.
So, as a rule, I always prefer a stable version… whenever it is available, unless there is some problem that affects my use, and that is being fixed in some beta version.
290 / 5.000
Resultados de tradução
Resultado da tradução
about the problem in question - updating Duplicati, do you think it can work: 1. export the backups, 2. uninstall, 3. install the current version, and 4. then import the backups and recreate the database with the version that is in storage? As if it were a total loss of the local machine…?
Then install from https://duplicati.com/download.
Preparing for that possibility by making exports is good, however mere uninstall leaves the jobs.
Practicing recreating the database is good too, but none of that is necessary in order to upgrade.
1 Like
Where do you see that?
Version 2.0.7.1 should not be able to see anything other than 2.0.8.1.
The order does not matter here, but the logic is:
- Anything older than 2.0.8.1 only looks at the field
RemoteURLS, which forlatest.manifestpoints to 2.0.8.1 - Version 2.0.8.1 also understands the field
UpdateFromV1Url(where v1 is the manifest version, not the Duplicati version) - If 2.0.8.1 sees a value in
UpdateFromV1Url, it will not try to download fromRemoteURLS, but instead just open the link founr inUpdateFromV1Url(which ishttps://duplicati.com/download).
The idea is that everything updates to 2.0.8.1. Once on 2.0.8.1 it then points to the download page that has the latest release.
Later versions use latest-v2.manifest which has a different signing method and a stronger key.
This seems to indicate that the zip package is somehow failing the validation check?
This can be ignored, it has no effect on Windows, and works on MacOS.
My install is a little odd (being from .zip) but here’s what mine looks like:
C:\Duplicati\duplicati-2.0.7.1_beta_2023-05-25>Duplicati.Library.AutoUpdater help
Usage:
Duplicati.Library.AutoUpdater.exe [LIST|VERIFY|CHECK|INSTALL|HELP]
Environment variables:
AUTOUPDATER_Duplicati_SKIP_UPDATE - Disables updates completely
AUTOUPDATER_Duplicati_POLICY - Choose how to handle updates, valid settings: CheckBefore, CheckDuring, CheckAfter, InstallBefore, InstallDuring, InstallAfter, Never
AUTOUPDATER_Duplicati_URLS - Use alternate updates urls
AUTOUPDATER_Duplicati_CHANNEL - Choose different channel than the default Beta, valid settings: Stable,Beta,Experimental,Canary,Nightly,Debug
Updates are downloaded from: https://updates.duplicati.com/beta/latest.manifest;https://alt.updates.duplicati.com/beta/latest.manifest
Updates are installed in: C:\Duplicati\duplicati-2.0.7.1_beta_2023-05-25\updates
The base version is "2.0.7.1_beta_2023-05-25" (2.0.7.1) and is installed in: C:\Duplicati\duplicati-2.0.7.1_beta_2023-05-25
This version is "2.0.7.1_beta_2023-05-25" (2.0.7.1) and is installed in: C:\Duplicati\duplicati-2.0.7.1_beta_2023-05-25
C:\Duplicati\duplicati-2.0.7.1_beta_2023-05-25>Duplicati.Library.AutoUpdater list
* 2.0.7.1_beta_2023-05-25 (2.0.7.1)
C:\Duplicati\duplicati-2.0.7.1_beta_2023-05-25>Duplicati.Library.AutoUpdater check
New version is available: Duplicati v2.1.0.2
C:\Duplicati\duplicati-2.0.7.1_beta_2023-05-25>
EDIT 1:
If I click the Show button, at least it’s consistent in it’s use of the top of the manifest:
What (if anything) is Show supposed to show? There’s no 2.0.8.1 changelog around.
EDIT 2:
As a quick guess from my Canary log above where it said:
might be comparing DisplayName between autoupdate.manifest in the .zip file, so
against DisplayName in latest.manifest, so
“Displayname”:“Duplicati v2.1.0.2”,
EDIT 3:
Thanks for explaining. This possibly explains why 2.0.8.1 users aren’t complaining.
Earlier today, I used curl to download various latest*.manifest with --remote-time
-rw-rw-r-- 1 1000 1000 87311 Dec 13 08:29 beta.latest.txt
-rw-rw-r-- 1 1000 1000 16826 Mar 5 02:31 beta.latest-v2.txt
-rw-rw-r-- 1 1000 1000 88059 Nov 7 05:58 canary.latest.txt
-rw-rw-r-- 1 1000 1000 18565 Feb 28 10:28 canary.latest-v2.txt
-rw-rw-r-- 1 1000 1000 87430 Nov 18 02:52 experimental.latest.txt
-rw-rw-r-- 1 1000 1000 16826 Mar 5 02:31 experimental.latest-v2.txt
and was wondering how the seemingly old files were causing trouble only recently.
Also why only for 2.0.7.1 users. You had mentioned the 2.0.8.1 updater is different.
I haven’t tested it lately, but one theory is this bug only affects pre-2.0.8.1 updaters, possibly only in the time after 2.1.0.2 came out. That would reduce the impact a lot.
EDIT 4:
Testing 2.0.8.1 Beta.
You are currently running Duplicati - 2.0.8.1_beta_2024-05-07
Update Duplicati v2.1.0.2 is available, download now
Show button or the link shown as text opens a new tab to the URL shown.
While I do like Show to show what’s coming (and download page doesn’t),
does this maybe leave an opening for (example) 2.0.7.1 to do just 2.0.8.1?
It’s currently going somewhat past where maybe it could have stopped, but
isn’t going all the way to v2.1.0.3_beta_2025-01-22 (but has no need to…).
I surveyed the non-v2 and v2 manifest files, and it looks like other channels
follow the same approach of going to same-channel version that can handle
UpdateFromV1Url as a transition assistant to get into the new .NET 8 ones,
which are the ones that look actually current with channels, as they must be.
Here’s a summary of manifests found on the updates site as of this morning:
Displayname ReleaseTime RemoteURLS UpdateFromV1Url
canary Duplicati v2.0.9.109 2024-11-06T14:00:00Z duplicati-2.0.7.103_canary_2024-04-19.zip https://duplicati.com/download-dynamic?channel=canary
experimental Duplicati v2.1.0.0 2024-11-15T14:00:00Z duplicati-2.0.8.0_experimental_2024-04-19.zip https://duplicati.com/download-dynamic?channel=experimental
beta Duplicati v2.1.0.2 2024-11-29T14:00:00Z duplicati-2.0.8.1_beta_2024-05-07.zip https://duplicati.com/download
v2.0.9.109_canary_2024-11-06
v2.1.0.0_experimental_2024-11-15
v2.1.0.2_beta_2024-11-29
v2 is current:
v2.1.0.110_canary_2025-02-28
v2.1.0.1_experimental_2024-11-25
v2.1.0.3_beta_2025-01-22
v2.1.0.5_stable_2025-03-04
Displayname ReleaseTime
canary-v2 Duplicati v2.1.0.110 - Canary 2025-02-28T15:25:11.259147Z
experimental-v2 Duplicati v2.1.0.5 - Stable 2025-03-04T22:13:56.501385Z
beta-v2 Duplicati v2.1.0.5 - Stable 2025-03-04T22:13:56.501385Z
stable-v2 Duplicati v2.1.0.5 - Stable 2025-03-04T22:13:56.501385Z
After tracking this, it is because versions older than 2.0.8.1 sees the update.
The idea was that they would update to 2.0.8.1, which would then suggest the later upgrade.
But as we discovered, the update fails because the manifest lists version 2.1.0.2 but the zip package to update with is 2.0.8.1.
The solution is to manually install the updated version.
My point (which may or may not be right) was that if the manifest at, say,
https://updates.duplicati.com/beta/latest.manifest
is the 2.0.8.1 one, then the checks would pass for a pre-2.0.8.1 Duplicati.
That would do as desired, taking the user to 2.0.8.1. Presumably 2.0.8.1
manifest provides 2.0.8.1 with its new
"UpdateFromV1Url":"https://duplicati.com/download for next jump.
Jump destination is unknown at 2.0.8.1 time, and is also a moving target.
Having once done a manual jump into the 2.1 versions, next will use the
https://updates.duplicati.com/beta/latest-v2.manifest
which is kept current. Question is do you have the old non-v2 manifests?
What I mean by that is probably those for the last non-v2 Duplicati made.
Per my summary above, Experimental may be 2.0.8.0, Canary 2.0.7.103.
My point was that these are two different URLs, so the manifest can differ.
EDIT 1:
Put the line above on hold. I’m thinking the problem is that 2.0.7.1 seeing 2.0.8.1 (when that shipped) was fine, but trigger for 2.0.8.1_beta_2024-05-07 to show a “Manual update required” dialog was 2.1.0.2_beta_2024-11-29 manifest’s arrival, which is also (as they share a URL) when pre-2.0.8.1 broke from the check code.
I thought I saw a post recently (maybe based on usage reporter stats) of how many users were on older versions. I don’t know how fixable this issue is, but leading a significant percentage of users through struggle, support need, or leaving is bad…
EDIT 2:
If the .NET Framework build, test, and release infrastructure still runs (e.g. to allow hotfix to 2.0), then if latest.manifest can use it (say it’s called 2.0.8.2), then 2.0.7.1 can update to it per original design idea, then 2.0.8.2 can have a fixed update plan, such as a different manifest URL, or even (very crude) coded to know it’s obsolete.
EDIT 3:
The (let’s call it latest-v1.5.manifest) could probably be what latest.manifest now is, pointing to 2.1.0.2, but not breaking from that, just as 2.0.8.1 doesn’t break.
EDIT 4:
If there are already some semi-hot fixes you’d want to put on 2.0, there’s a chance for 2.0.8.2 to not be purely an updater retry, but I’d sure hate to add any regression.