How to get rid of "The option compression-level is deprecated: Please use the zip-compression-level option instead"

Support
1

Hi,

I have set up a back up and started it. Then I got warned “The option compression-level is deprecated: Please use the zip-compression-level option instead”

Fine, I changed the backup option to “zip-compression-level”. But still, Duplicati permanently complains in a warning “The option compression-level is deprecated: Please use the zip-compression-level option instead” - this e.g. happens on restore.

Since the warnings are pretty annoying from UI point of view (you find the relevant part in between a bunch of log stuff), how can I get rid of it? Repair database?

Thx

2

Solved, my mistake. I saved both options, zip-compression-level AND compression-level.

3

I’m glad you figure it out!

But in an effort to keep it from happening in the future I’m going to ask @kenkendk if there’s a way to support legacy parameters (like --compression-level) so existing backups that use them don’t break, but choose to NOT show them in the UI anymore?

(I didn’t already ask this question, did I?)

4

I think this might already be handled correctly

In latest Canary when I test this I do:

  • Create job
  • Set compression-level
  • Run backup
  • Job completes
  • Read warning about deprecation
  • Change from compression-level to zip-compression-level
  • Run backup
  • Job completes, no warnings

The warning seems to be entirely informational as in the compression-level is already translated into zip-compression-level in the backend so the backup functions the same. I can even restore all the files after changing from compression-level to zip-compression-level

So the warning is just to get people to change their configuration to be valid, but it doesn’t actually make a difference during the backup.

5

Yep. The current design does a good job of gracefully handling it situation, but I figured not listing multiple items in the first place might improve user experience.

6

Ah, I misread that part.

I think there might be an issue because of the way advanced parameters are added/removed. If compression-level is removed from the option list then it can no longer be removed after upgrading.

But yeah, it’s a bit confusing with two.

7

I ran into the same issue when I started - with both the --compression-level / --zip-compression-level parameters and the test-filter /test-filters commands (which happen to be the same thing, btw). :slight_smile:

8

Just wait until you start using a parameter file on CLI, supported options are:

  • parameters-file
  • parameter-file
  • parameterfile
    :slight_smile:
1 Like
9

Ahhhh…run away…run away!!! :scream:

2 Likes
10

OH NO!
“parametersfile” is missing! And typo handling. All incarnations again with “fiel”! And param/params!

2 Likes
11

I’ll get right on writing an emergency fix for that :smile:

What if we just string compare and assume anything closer than a 60% match means they want a parameterfile?

12

I don’t know - I’ve found fuzzy logic like that generally makes a good percentage of things slightly improve and a small percentage of things spectacularly blow up (in ways that become harder to debug).

However, not having personally used any variant of parameters-file I don’t know how big an issue this is hoping to resolve.

13

For command line options you just need to be firm. Offer one or two options.

But I still think fuzzy matching CLI interfaces would be hilarious until you have to troubleshoot random commands breaking when new commands are released :slight_smile:

1 Like