Should be promoted to the experimental channel?

Hi there!

We have almost completed all issues for the next milestone. Only a testing issue is still open. Do you think this version deserves to get promoted to the experimental channel?

  • Yes, it should become the next experimental.
  • No, there are still issues that need to be fixed.
  • Experimental? Make it beta!
  • I don’t know but like to vote.

0 voters

Give it a little while. I’m troubleshooting problems, which may be related to, completely breaking my backup :wink:

Alright, it turns out to not be a bug but just the fact that “Linux default filters” are actually applied now, because of Fix default filters in server / UI by tygill · Pull Request #3023 · duplicati/duplicati · GitHub, removing anything in /etc and /var which was definitely not my understanding of the filter.

I’d vote for a “let it bake a while longer” option.

I don’t undestand. Does duplicati- install only *.exe?

C:\Program Files\Duplicati>dir *.exe
Том в устройстве C не имеет метки.
Серийный номер тома: NNNN-NNNN

Содержимое папки C:\Program Files\Duplicati

31.01.2013 14:42 19 456 Duplicati.CommandLine.BackendTester.exe
31.01.2013 14:42 37 888 Duplicati.CommandLine.Decrypter.exe
31.01.2013 14:42 94 720 Duplicati.CommandLine.exe
31.01.2013 14:43 1 456 640 Duplicati.exe
31.01.2013 14:42 33 280 Duplicati.Library.SharpRSync.exe
31.01.2013 14:42 53 760 Duplicati.Library.Snapshots.exe
6 файлов 1 695 744 байт
0 папок 60 348 280 832 байт свободно

My setup options avaible this:

I want to use D2 as service.

I believe it’s the same installer as with the other releases. You should be able to get it to run as a service

Do you see “Duplicati.WindowsService.exe” among my 6 files? I downloaded file from this page:

If it didn’t extract from the installer, try to reinstall it or just download the zip file and copy the missing files over.

In additional at home I upgraded D2 from from 17 and before from 16. But Duplicati.WindowsService.exe has version For me it’s strange and may be ver 17 and 19 doesn’t contains this files.

of course, no. I attached screenshoot my D2 setup.

Do you really think that it’s normal for new user to install and download missing file?

Honestly, it’s a canary build, if the user isn’t comfortable troubleshooting issues the user should be using a more tested release like the beta or experimental release.

I’m sure someone would like to help, but I think you’ll have more luck getting help if you open a new topic instead of posting on the release note page.

Thank you. But I don’t need help now)) So, you’re answered to subject question))

It shouldn’t be promoted to the experimental channel! :smirk:

OK guys. If issues need to be fixed, please give me a list if github issues that we should include for the next experimental.

I took the liberty of tagging Revise default backup filters · Issue #3030 · duplicati/duplicati · GitHub to the experimental milestone because the filter is much too strict now.

Besides that I think we’re looking at:

Additionally, @kees-z and I were discussing two alterations on --retention-policy that I think would make sense to add before retention policy was released to everyone to avoid confusion if added later. The first being a semantic U notation for unlimited (U:1M instead of writing 200Y:1M and 1W:U instead of 1W:0s). And the second being a K notation for keep as there are some things you can’t do like 1M:1D without risking ending up with just a single backup if your machine is offline for longer than a month. New retention policy deletes old backups in a smart way

And we should have a couple of people running windows try and replicate the above problem with Duplicati Server not upgrading when using the windows installer. Not worth much pushing updates if no one gets them :slight_smile:

Let me summary this:

  • Default filters were fixed. We are concerned that they might filter too many files and folders now. We should revise the rules, to make sure, noone who has activated any system filter is missing files after an upgrade. Good point.

  • We are still testing the retention policy and would like to introduce two more options. One covers the entire future to avoid rules like 100Y:1M. The other is there to make sure that there is always a minimum number of backups before the deletion kicks in. Suggested notations are: U:1M and K:30. I agree on the testing. I don’t think we need U and K for an experimental release (unless someone gets this implemented quickly).

  • Issue #3010 was reported once. Nobody could reproduce and the user did not give any feedback so far. I would prefer to ignore this.

  • Windows server: Is there an issue on github?

PS: I see that you are very dedicated to chase some of the newer issues. We still have a lot potential to improve Duplicati for many people. E.g. the update notification comes in through various channels and if you choose to update from the about screen, there are multiple progress bars. This is something that deserves our attention. But not for the next experimental version. :slight_smile: If you like, we could start a discussion about this as the next major thing.

I think this one may be related to the issue with --keep-time and --retention-policy throwing not-that-user friendly errors when combined. They may be the same issue.

Not that I know of. I haven’t had the opportunity to try to replicate as I just saw it here on the forum. Maybe skip it and deal with it if it turns out to be a problem? :wink:

I think I can get U in with like 2 lines of code just translating it to 0s and before running the retention policy method since it’s just semantics. Never mind, it’s a bit more tricky. The K is very cool, but I also fear it may be quite a bit more work to implement. If we’re just aiming to ship quicker so we can get to next experimental release sooner, then it might not be terrible to just ship it as is once we handled the showstoppers

I’m pretty sure it contains the files as I just (2 hours ago) did a duplicati- install on a new machine (English Windows 10) without issue.

Following the above linked service process (including using Duplicati.WindowsService.exe) also worked just fine.

My guess is there’s an edge case with how an MSI update (not to be confused with a GUI update) is handled vs. a fresh install.

1 Like

Thanks for testing :slight_smile:

Agreed. I think historically trying to squeeze that one last tweak in is what slows down releases.