Should be promoted to the experimental channel?

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.

Heh, it wasn’t actually a test. A client’s backup drive filled using Windows backup so I decided to switch them to Duplicati.

And yes, I know it’s canary - and yes, I still feel confident it will work as needed. :slight_smile:

Anything that could replicate an issue and could provide data about the issue is a test in my book :slight_smile:

Just check the filters :wink:

2 posts were split to a new topic: OS level filters

Sorry to you and all people)) I search files on D1 path, not D2).

So, v19 must be experimental!)

8 posts were split to a new topic: Missing AlphaVSS.x64.dll error on clean install

I vote for 3032. Live logs are visible again in Chrome but otherwise things have gotten worse.

1 Like

#3032 is fixed by a super tiny update #3033, so it should be easy to include that :slight_smile:

1 Like

I have lost the overview as it always happens when we scramble to get a release ready :slight_smile:

I have updated the milestone with some minor tweaks: 2.0.3 experimental Milestone · GitHub

Should we have a go at fixing those issues, or roll with

1 Like

It’s not easy :slight_smile:

I think we’re close once we merge #3052 and fix #3055. I feel like we’ve been quite a few people testing the retention policy without anything blowing up :slight_smile:

1 Like

Wow, #3055 is now fixed!