- Added support for setting low IO priority during backups
- Changed order of throttling arguments to fix incorrect throtling
- Added an option to disable backups when running on battery, thanks @warwickmm
- Fixed a crash on the CLI help page, thanks @tygill
- Added new Graph-API based backends for SharePoint and Office 365, thanks @tygill
- Added new UI status badges, thanks @dbddhkpde
Also, I don’t think the Graph API backends will work quite yet (unless you generate your own AuthID), as it looks like the Duplicati OAuth service hasn’t been updated to include the new protocols. The pull request has been accepted, it just looks like the new version hasn’t been deployed.
The problem is that the style.less is not “compiled” to generate a new syles.css. I modified only the less-file and did not add the compiled styles.css to my commit.
Thought this is done automatically whenever a new release is created, sorry!
Does this functionality outright skip backup jobs? Because I think it would be better if the “on battery disable” acted somewhat more like having duplicati paused, in that when plugged back in, there would be a queue of (up to 1 of each i suppose) backup jobs ready to run.
The way it’s implemented now, a scheduled backup is simply skipped (although clicking “Run now” while on battery will still run the backup).
Having the skipped backups run upon plugging in would be really nice. I think there may be some subtleties that we would have to be mindful of. For example, suppose a backup is skipped while on battery and enqueued. While still on battery, the user then edits the settings for that backup. Which “version” of the backup would users expect to be run upon plugging in?
I’m not 100% sure how this is handled now, but I would expect it to be handled about the same way that un-pausing duplicati handles it (if it’s actually handled at all). And in general I would think if 2 instances of a job queue up against each other, the latest ‘version’ would take precedence and supersede the previous one.
Ok. I created an issue in GitHub to keep track of this feature request.
Yes, I have a lot of loose ends I need to tie up, but I will update the service as soon as I have time to monitor it afterwards.
I have not figure out what the best strategy for dealing with this is. It could be part of the build script, but then we end up having some latent issue that only shows up after a release. It would be nice if we could rebuild the
.css file during normal builds, but I don’t like tinkering with the VS project files for that.
One possibility is to use a pre-commit (or pre-push, etc.) hook. Newer versions of Git allow you to specify the location of the hooks directory, which allows the hook scripts to be committed as part of the repository as well. We can then potentially reject the commit (or push) at some point if compiling the style file results in a dirty working tree.