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.
Yes. But.
If you are running 2.0.8.1, then there is no new update if the version field says 2.0.8.1, so it will not show the update from UpdateFromV1Url in this case. Changing the version number to any other value than 2.0.8.1 will make the older versions reject the update.
In hindsight, I should have added two version fields to support this case, but I failed to test the scenario of using the built-in updater to go up in versions, I just tested that it would show the update (which it does).
Yes, at least some of them. The previous build system did not retain all old versions of the manifests.
Not really, because 2.0.8.1 reads the /latest.manifest and does not look for latest-v2.manifest.
I still have a build environment for that, but I would prefer not to release any more mono-based stuff, as it detracts resources from moving forward.
I gave my own “But” with “Put the line above on hold” in EDIT 1, then kept going.
Pre-2.0.8.1 would keep version and download aligned at a new 2.0.8.2 release.
2.0.8.2 sees 2.1.0.2, but can be coded with regular is-version-greater check even though we know there’s already a greater version. This follows UpdateFromV1Url.
So right below that quote was my retraction, and then the new proposal is given.
All the arguments being made against original proposal seem to ignore later one.
This is a little bit like what I’d suggested, except I’d proposed it be done serially.
Let’s say 2.1.0.3 Beta wasn’t out yet (just 2.1.0.2) in order to show 2.1.0.3 jump:
Old manifest URL version New Mechanism
2.0.7.1 latest.manifest 2.0.8.2 automatic
2.0.8.2 latest.manifest-v1.5 2.1.0.2 manual
2.1.0.2 latest.manifest-v2 2.1.0.3 manual
Theory is that a 2.0.8.2 might be as easy as 2.0.8.1 with a different set of URLs.
It’s sort of a business decision, possibly informed by the usage reporter statistics.
For for-profit company, losing customers (or at least potential ones) should worry, however there’s also a question of which ones. Some might stay on 2.0 for years.
Someone on the business side of Duplicati, Inc. might have thoughts on direction, however beyond that is the question of user impacts, “right thing to do”, and so on.
If code is harder than I think, then sorry. I’m on second try. Any big technical gaps?
EDIT 1:
Let me try looking for gaps in table above, and consider the available materials.
The troublesome current latest.manifest could be moved to latest.manifest-v1.5.
This has 2.1.0.2 as its version but points to the 2.0.8.1 .zip file, breaking 2.0.7.1.
The replacement latest.manifest is new 2.0.8.2, built to use latest.manifest-v1.5.
This doesn’t download a .zip, but follows the UpdateFromV1Url for manual work.
The manifest is already set up this way, so that gets to 2.1.0.2. Past that is usual.
Beta channel seems to avoid 2.1.0.3 (likely a good idea) and go to 2.1.0.5 stable, which has some fixes that are in none of the other channels. How to keep testers around? Most Beta channel users probably want Stable, but some might do Beta.
From what I can see:
- 2.0.8.1: 23%
- 2.1.0.5: 11%
- 2.0.7.1: 17%
- 2.0.6.3: 15%
- 2.1.0.2: 8%
- 2.1.0.4: 7%
- 2.0.5.1: 5%
- 2.1.0.3: 4%
So there is certainly a large install base on older versions. But given that 2.0.7.1 installations has received update notifications for around 10 months without choosing to update, I am not sure how many we can catch with an updated build. For 2.0.6.3 it is one year more.
Given that the downside of the current situation is that users on old versions need to manually update (which is required anyway), I don’t see a big upside to doing this.
I think the update would be to change 2.0.8.2 to ignore the version field if the extra url is there. This would allow the manifest to have the 2.0.8.1 (or 2.0.8.2) version and accept the update for older installations, and just show the update on 2.0.8.2.
The testing part of this requires some planning to make sure it does not make it worse.
And then there is the signing part. Releasing a new build requires that the build system from 2.0.8.1 is changed to use the new signing keys, which require updates to the scripts etc.
But… fixing this would only make it smoother to upgrade to 2.0.8.1/2 which would then immediately suggest updating to 2.1.0.2 (but lead to 2.1.0.5).
Thinking it through once more, there is no need to do any of that. The 2.0.8.2 version could just have a hardcoded update prompt, because that is where it will end up anyway.