Yes, true. The latest versions (canary builds) do not have the updates folder, which is present in v2.0.8.1 and older.
Easiest way to find the folder is to run Duplicati.CommandLine.AutoUpdater.exe (aka duplicati-autoupdater ) in a command prompt and it will tell you what directory it is using. This approach works both before and after v2.0.8.1.
Edit: And the file is called installid.txt in v2.0.8.1 and older, but was split into two files with v2.0.9.100.
OK, here is the explanation for the backups not being logged on the new hub:
On the two laptops (and only there) I had set up the jobs to be logged on the “old” monitoring website duplicati-monitoring.com. I did read the note that monitoring can only go to a single point - but for some reason my brain reverted the logic of the note in global advanced options and thought that the global options would override the job-specific ones. Now I proved that it is the other way round, as correctly stated.
In short: the problem was in front of the keyboard, not in the program 
Thanks for helping me think …
As for the discussion about what is in which release: I can’t quite follow you about installid.txt machineid.txt or the update folder - I can’t find either anywhere in the installation or in the local-appdata folder (using 2.0.8.1_beta_2024-05-07)
Great to hear that it got solved 
What is the output of running Duplicati.CommandLine.AutoUpdater.exe ?
Mine says something like:
Usage:
duplicati-autoupdater [CHECK|DOWNLOAD|HELP]
Environment variables:
AUTOUPDATER_Duplicati_SKIP_UPDATE - Disables updates completely
AUTOUPDATER_Duplicati_URLS - Use alternate updates urls
AUTOUPDATER_Duplicati_CHANNEL - Choose different channel than the default Stable, valid settings: Stable,Beta,Experimental,Canary,Nightly,Debug
Updates are downloaded from: http://updates.duplicati.com/debug/latest-v2.manifest;http://alt.updates.duplicati.com/debug/latest-v2.manifest
Machine settings are installed in: ...
This version is "Current" (1.0.0.0) and is installed in: ...
The two last lines points to folders on your machine, and the file installid.txt should be in the folder noted by Machine settings are installed in.
Hmmm … mine says:
[…]
Updates are downloaded from: https://updates.duplicati.com/beta/latest.manifest;https://alt.updates.duplicati.com/beta/latest.manifest
Updates are installed in: C:\ProgramData\Duplicati\updates
The base version is “2.0.6.3_beta_2021-06-17” (2.0.6.3) and is installed in: C:\Program Files\Duplicati 2
This version is “2.0.8.1_beta_2024-05-07” (2.0.8.1) and is installed in: C:\ProgramData\Duplicati\updates\2.0.8.1
no mention about Machine settings are installed in: ...
However in C:\ProgramData\Duplicati I find a file installation.txt which contains what could be a installid (32-char, obfuscated)
c49xxxxxxxxxxxxxxxxxxxxxxxxxc5
This file is used to track the number of unique installs.
The first line in the file is used as an ID, which is sent to the server when checking for updates.
If the first line is blank, this installation will not be part of the usage statistics.
So I’m not sure what kind of installation (version, OS dependent?) you are referring to.
Probably a Duplicati version dependent thing. Testing on 2.0.9.100_canary_2024-05-30
Machine settings are installed in:
and if I look there, there is the new machineid.txt and the old installation.txt with same ID.
Testing on 2.0.8.1_beta_2024-05-07
Updates are installed in: with installation.txt but not machineid.txt which came later.
Remember: machineid is new. When I look in the portal, I see this value in Machine Name.
I doubt that it’s obfuscated, but I think by design it was supposed to be random and unique.
For 2.0.8.1 and older, are you encouraging editing installation.txt? That will reduce uniqueness.
installation.txt explains:
This file is used to track the number of unique installs.
The first line in the file is used as an ID, which is sent to the server when checking for updates.
If the first line is blank, this installation will not be part of the usage statistics.
machineid.txt (for those who have it) explains:
This file is used to assign a unique ID to the machine, and used to identify the machine in reports.
The first line in the file is used as an ID, but can be changed with --machine-id for a single or multiple runs.
I doubt that it’s obfuscated
No, it isn’t. I obfuscated it (replacing with xxx) before pasting just in case it would disclose some private information…
My confusion is about mixing installation.txt and installid.txt in the previous posts:
And the file is called
installid.txtinv2.0.8.1and older,
which is not what I see in my installation of 2.0.8.1
For 2.0.8.1 and older, are you encouraging editing installation.txt?
I guess this question goes to Ken
If you have installation.txt, I have 40 on my system in various Duplicati related things.
I have no installid.txt anywhere on my drive, according to Everything (instant search).
If that’s not convincing enough that this was probably just a miswritten name, code is
2.0.8.1:
Also I can’t find any installid.txt in an older local source copy.
Question remains what one should do with an installation.txt.
That was my mistake, sorry. The internal variable is called installid but the file is called installation.txt.
The ID in this file is just an autogenerated Id used to keep track of how many different machines are running Duplicati. It is intentionally random and not sensitive to disclose.
I split the installation and machine-id into two files in later versions, so it is possible to opt out of being counted by the usage reporter, and still use a machine id (or vice versa).
For 2.0.8.1 the easy way is to change installation.txt, but otherwise you can set --machine-id in the advanced options. It only affects the usage reporter count and machine-id.
Thanks Ken for the clarification.
going back to my note from June 24, it seems like this is not exactly true: Looking at the log on duplicati-monitoring.com I see that my successful jobs get logged, but all with “unknown” result. This only happens when I have the monitoring option (send-http-url) set in the general options (to Duplicati hub) and in the job itself (to duplicati-monitoring.com).
I would expect that the job-specific option overrides the general option in all aspects, so I can leave both in, if I want logging on duplicati-monitoring.com.
However only when I remove the general option, I get a “successful” result logged on duplicati-monitoring.com. Else it shows “unknown” and eventually triggers warnungs and errors for “unsuccessful” runs.
Background: For the time being I would like to easily switch between logging on the Hub and the old monitoring website, by temporarily en-/disabling the job-specific send-http-url option, leaving the general option untouched.
My best guess is that the option --send-http-result-format is not edited at the same time as the --http-send-url, so you are sending json data to a destination that expects the text based format.
Hmm… so you mean this is nothing under uersr’s control, right? Then we should probably reword the note that says that general options overwrite job-specific options to something like “… same option specified at both locations may collide and produce unpredictable results”
No, it is fully under the users control, but url+format go together. If you mix them, it will most likely fail in some way.
Say you have application settings for url+format set to A and backup settings for url+format set to B. If you end up having url set to A and format set to B (or vice versa) it will fail.
The general idea is that the are “Default settings” (aka application settings) in the settings area are intended to choose different defaults than what Duplicati would normally use. This way you can set up various common options that you would like applied to all backups.
If you then want a special setting that applies only to a single backup, you can set it on the backup. General rule is “the closer the rule is to the target, the higher priority”.
The chain is then Duplicati default → Default settings → Backup settings, where each step will overwrite the previous if it is set.
Overwrite means that it will replace the entire setting, it is not possible to “append” values as that would not make sense for most options. In other words:
Duplicati: --opt1=a
Default settings: --opt1=b
Backup settings: --opt1=c
will result in --opt1=c being applied, it will never be abc or similar.
Hope that makes it a little clearer.
Ah - I see. So I need to make sure that not only the send-url option but also the send-http-result-output-format specified in the default options gets overwritten in the backup settings. So far I didn’t set a format in the backup option for logging in duplicati-monitoring.com, probably because it uses some default “Duplicati” format. But if I do specify the format explicitly as “Duplicati”, then the default does get overwritten completely. Alternatively: if I switch the format in the default option from Json to Duplicati (with no format option in backup). Tried both alternatives successfully!
A different observation:
On the Hub dashboard some of my backups showed up in he Alert Center with an “abnormality report”.
I can click on the red alert button to the left, but nothing happens.
Looking at the detail information for this run under Backups doesn’t give me a hint either. So where should I look to find the reason for this “abnormality”?
And a process question: Would you prefer further questions related to the new Duplicati portal to be submitted in separate threads? I feel a bit uneasy continuing this one forever …
We are still refining the UI around the notification hub, and it is prepared to show you the actual notification contents, but this part is not fully ready. We did recently change notifications to include more information, so you can set up email notifications and see the details until we are ready with this information in the notification hub.
Generally, the forum is for stuff that relates to the open-source project, so I would prefer to have questions about the portal asked via the support button in the portal. But we do monitor both the forum, Github and the support tickets and accept that things tend to be fluid.