Had an odd one today. Visited an office where I had three copies of Duplicati running on Windows 10. Standard install, not a Service version. They were setup to do a backup via SMB to one of the three machines via the network share.
Backups seemed to be working, no errors. Then I spotted something odd.
Looking on the ABOUT page it told me it was v2.0.4.5_beta_2018-11-28 but when I looked at the Settings page I was told it was v2.0.3.3_beta_2018-04-02
How did that happen? It was a quick fix as I quit the app, downloaded fresh, installed on top.
Now both locations show v2.0.4.5_beta_2018-11-28
I do also have other puzzles… like why the interface keeps swapping back to White. Always a bit odd when things are not as one leaves them.
Thanks @Pectojin - at least that stops me worrying about the theme. As I usually am using Private Mode to launch the browser that will explain why it looses its pretty looks. I can also be very inconsistant as to which browser is launched.
Why is the theme not stored with the rest of the settings? Or are there other settings from that config page that are lost with deleted cookies \ browser swaps?
The manual update I did today was the more assured way. Stop the app from the task tray, downloaded latest from website, install on top. So that makes sure it got all sides.
Just seemed weird that a program can argue about its own version - About and Settings being different. The secondary point is that the Settings was therefore also telling me I was on the “latest beta” but listing the previous beta.
Yeah it’s a little weird with the version numbers. It shouldn’t happen.
I think the original reason the theme is in cookies is because we have no user management system so theme change would have to be for everyone. Although it’s also pretty likely it’s just this way cause someone just went with it
That theme changing has often been a worry to me. Previously I had used theme changes to assist when I was swapping between “normal” and “service” installs on a PC. I thought that theme was helping me spot the difference.
NOW I understand what was going on - this post has been worth it.
I kinda guessed “it shouldn’t happen” with the version numbers. Hopefully this nudges someone to look at why the two different pages are looking in two different locations. Would make more sense to me that they should be using the same function call to check that kinda info.
Visited another client today, and found the same confusion over version numbers. This was a “Run as a Service” based install. And I thought I had manually updated some of these myself via the 127.0.0.1 webpage.
I now know for sure NOT to use the built in updater. Just make sure ALL versions are exited. The service STOPPED. And then manually run the update.
For what it’s worth I think it’s just a cosmetic bug.
The build in updater can’t overwrite itself, so what it does it placing the updated files in an upgrade directory within duplicati. Then next time duplicati starts it will load what is in the upgrade directory instead of its original version.
Technically a tiny part of the running program is still the original version this way, but 99% of the code running is the new version so it’s virtually identical to use either method.
Yeah, it is cosmetic but does also imply something is a little confused. Why does the Settings page read from a different place to the About page?
In the past week, every time I have cleared this by making sure everything is stopped manually and not using the webpage’s update ability. Fully closing the web browser to perform the update from the manually downloaded installation package.
Could I suggest a separate updater application? One that can run separate and force everything “Duplicati” to be shut down for replacement? Exit the app, stop the service, quit the browser admin page. It gets a bit unnerving when the application is in an unknown state of being somewhere between versions. Even if it is only the web GUI that is confused.
This is just small beans feedback - I realise there are bigger issues to fix with the other threads on the database rebuild pains.
TL;DR Versions are different because one is the base (original install) and one is what’s currently running. The base version also sets the Default update channel, as is (not so easily) understood from its context.
I think the intent of the Settings “Update Channel” section is to allow the user to choose an update channel, and the Default update channel is based on the original install version, which is known as the base version.
Systems that had original install of v2.0.3.3_beta_2018-04-02 and upgraded to v2.0.4.5_beta_2018-11-28 would still default the update channel based on v2.0.3.3_beta_2018-04-02, so default to the beta channel.
Though this is somewhat obscure and confusing, especially if one doesn’t understand the updater plan, a clearer view of what one is running is found in several other places in About, for example the initial screen About → General says You are currently running, the Changelog screen should confirm this (as it’s presumably a direct reflection of the folder actually used), and the System Info screen shows lots of detail such as what you are running now (the Server names), what you originally installed, and how it set default update channel. Maybe the Settings Update Channel Default text should explain more about its statement?
ServerVersion : number
ServerVersionName : - number_type_date
ServerVersionType : type
BaseVersionName : number_type_date
DefaultUpdateChannel : type
The reason there is not a separate updater application is probably due to permissions needed to do everything listed there which needs administrator privileges. For example, a Windows “Standard User” might not receive automatic updates. Whether or not they ought to receive them is a different debate. Administrators with privilege already have an updating mechanism using the OS methods, e.g. .msi.
Activate downloaded upgrade sometimes fail shows the bug in the updater for service installs, a repair attempt, and its retraction because of issues (not well-understood) it caused. As far as I know, service install can use the automatic update, but someone then must run manual service restart or reboot PC.
Personally, my wish would be for automatic updates to actually work as they claim, but bugs exist, and probably the non-service install works better. There are plenty of other service rough edges remaining… Opinions might vary, and anybody can suggest whatever Features they like, make a case, and discuss.
