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?
Solved, my mistake. I saved both options, zip-compression-level AND compression-level.
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?)
I think this might already be handled correctly
In latest Canary when I test this I do:
- Create job
- Run backup
- Job completes
- Read warning about deprecation
- Change from
- 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
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.
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.
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.
I ran into the same issue when I started - with both the
--zip-compression-level parameters and the
test-filters commands (which happen to be the same thing, btw).
Just wait until you start using a parameter file on CLI, supported options are:
Ahhhh…run away…run away!!!
“parametersfile” is missing! And typo handling. All incarnations again with “fiel”! And param/params!
I’ll get right on writing an emergency fix for that
What if we just string compare and assume anything closer than a 60% match means they want a parameterfile?
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.
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