This is a very special case in Windows Setup (tested on Windows 11 OS), just reporting it for completeness:
If an additional drive is mounted when starting the setup exe but unmounted before actual installation starts, setup aborts with an error. Note that the additional drive is not selected as installation location. Step-by-step instructions:
Mount a drive (in my case, mounted to A:\)
Start setup (tested for duplicati-2.1.0.5_stable_2025-03-04-win-x64-gui.msi)
Check location in Customize Duplicati step (not pointing to the mounted drive but to permanent drive C:\)
In addition to the bug, I have a question regarding the installation:
I tried to use the setup to update an existing installation but missed out that the existing installation location was non-default (instead of default C:\Program Files\Duplicati 2 it was something like C:\Program Files\duplicati-<version-number-channel>).
As I did not modify the default installation location for the update, I do have two Duplicati installation folders now. Starting and using Duplicati from the new installation location appears to work. I am not sure how the old duplicati version was installed (whether using an installer or maybe just extracting a ZIP file?).
Can I just delete the old Duplicati folder (C:\Program Files\duplicati-<version-number-channel>) or are there any other things to consider or cleanup?
I was able to reproduce it and with msiexec /i duplicati-2.1.0.5_stable_2025-03-04-win-x64-gui.msi /L*v install.log I was able to collect the extended logs of the MSI installer.
Right in the beginning of the installer there is an event:
PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'B:\'.
It hit me to test mapping a letter further down the alphabet than C:\ so I created a T:\ mapped and did the same test, which installed without error, even disconnecting T:\ in the same stage as the test case, and the log then shows:
PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'C:\'.
So it seems to be a behavior of the MSI installer to select the ROOTDRIVE as the lowest alphabetical drive. I am not certain we can prevent that, but we can investigate. In any event its a non critical edge case, just interesting.
On the other part of the question I am not certain, I hope someone else can clarify.
Nobody else can tell you what you have in there that you might want to keep.
Providing an actual name would help, as form doesn’t exactly match a .zip.
Example .zip names would be duplicati-2.0.8.1_beta_2024-05-07 or duplicati-2.1.0.3_beta_2025-01-22-win-x64-gui, so also a date at end.
The 2.1 .zip files start with a folder at top. The 2.0 gets right into the file set, making an easier opening for you to invent your own folder name for the files.
Regardless, there would be a changelog.txt file with version number at top.
Starting in --portable-mode (not likely?) maintains an important data folder.
You can generally notice things made after creation by sorting the files by date.
Better is Explorer search box file:*, then change View to Details for sort.
Best is extract suspected version from .zip then compare with mystery folder.
You should be sure you stopped any old Duplicati that might be running from it.
If happy there’s nothing to save, you can be extra careful and rename it for test.
You’re right, I’m sorry for the inaccuracy, I did not have the exact name available when writing. I have looked it up today, it is: duplicati-2.0.6.3_beta_2021-06-17
I also found the corresponding installer in the Downloads directory: duplicati-2.0.6.3_beta_2021-06-17-x64.msi
Thus it is most likely installed using the setup installer. Not sure whether the folder name was proposed in the setup process or manually set. The checksums of all files are identical with the checksums of the released files for release 2.0.6.3_beta on GitHub. The files present also have 2021-06-17 as creation date (only the folders are dated 2022-06-03 which might represent the actual installation date). However, I am confident to have performed in-application updates in the web UI since then as long as they were supported (2.0.7.1_beta, 2.0.8.1_beta - there also exist backup <jobname> <backupdate>.sqlite files from 2023 in the %userprofile%\AppData\Local\Duplicati directory), which raises the question whether the installation directory could have already diverted at that time?
It does however seem questionable to me because then my regularly-used shortcut to the Duplicati.GUI.TrayIcon.exe would have started the wrong version after the update, which I would expect to trigger another update reminder and possibly issues in subsequent backups. The “wrong” shortcut destination of the start menu shortcut was the detail that led me to encounter the duplicate Duplicati installation in the first place.
Current status is that the old Duplicati.GUI.TrayIcon.exe is renamed. If there is no reason to doubt the integrity of the application data (especially SQLite databases, backed up data on backup destination), I would just delete the old duplicati-2.0.6.3_beta_2021-06-17 directory.
There were at least no warnings when running an existing backup job right after updating to 2.1.0.5_stable.
Feel free to let me know if I am just overly anxious or whether all that sounds like I should spend time to double-check that data integrity is ensured.
Sorry for all that mess, unfortunately I did not notice the duplicate installations earlier…
2.0 in-application updates leave the install alone, keeping updates elsewhere.
The 2.0 plan used the install as a launcher for latest version, thus no reminder.
Wrong how and when? Barring bugs and fallout from the mishap, I’d have thought installing 2.1 would produce a shortcut to its newer Duplicati in its normal location.
Some things can be deconfigured, e.g. start at login, but I think menu is mandatory (I’m not an installer dev, but you’re also talking to someone who seems to know it).
If you mean old shortcut to 2.0.6.3, its date could be checked for hints as to maker.
If jobname means random letters or digits, they might be job database backups.
Generally these are not useful for long, as they get obsolete quickly with backup.
To be super-safe you can rename, but you checked all the files, so likely no worry.
If you have other jobs, it might be safest to at least sanity check health a little bit.
Unless you have to do things like connect a drive, Verify files takes seconds.
This will update the job database version (probably leave a new .bak file), and do some DB self-tests, and probably about three file downloads from the destination.
Your inspection and one backup seem good, some perceived worries might not be abnormal, given the 2.0 design (old shortcut is a mystery), so you’re probably fine.
I’m glad to hear that, in my case the updates were installed to the former path a. (ProgramData).
When I used the Windows context menu Open file location feature on the shortcut, it led me to the original installation directory duplicati-2.0.6.3_beta_2021-06-17.
My first reaction after realizing there is an “old” installation was to delete the shortcut pointing to it to avoid further mess by accidental execution of it, so that mystery might stay unresolved.
Verify files was successful with no warnings or errors, so I’m confident that everything is fine. Thank you for your support!
