Restoring plugins will casue a headache when (they are large and) the central storage was removed in the mean time. Since it's current policy to ignore plugins _anyway_ when backing up, the simple solution is to also just don't restore them, even if they where present to begin with. Of course this is also applied to other to-be-ignored files and folder types.
should 'fix' CURA-8666
The file may not exist. In fact, that may be the whole reason why people want to restore a back-up. Try it, and give an error if it fails.
Fixes Sentry issue CURA-2QT.
We now allow the backup to fail gracefully when partial files
fail to be restored. But the user is not actively informed by
these failures. Leaving him/her unaware of the state of his
configuration folder.
This commit show's a message windows, listing the failed files.
Due to a string freeze at the moment we reuse the following i18n
message:
> The following error occurred while trying to restore a Cura backup:
followed by a list of files that fails to be restored.
Which is not ideal, but a sufficient warning in my opinion. At least
better then being completely uninformed.
Contributes to CURA-8313
Sometimes, while a backup is being restore, one of the files in the current config folder may be still in use. This means that once the backup tries to replace this file with the one in the backup, the entire backup restoration fails and half the configuration folder has been messed up.
To prevent that, we decided to ignore files that are currently in use while restoring a backup. This _may_ lead to a slightly wrong configuration (e.g. a plugin may not be restored properly), but it is an acceptable result, as the rest of the configuration folder is restored properly.
CURA-8313
To prevent the UI from being frozen. This way, the user knows that something is happening in the background and Cura didn't just stop working.
CURA-8313
Before calling the illuminate, we need to make sure that the previous cached Preferences have been overridden by the newly restored preferences from the backup. Otherwise, the `illuminate()` function will bring back the cached preferences and the new ones from the backup will be lost.
CURA-8313
Because we're adding a messgae for the user if the loading of a plugin failed
(which can happen after backing up a plugin in central storage), we can re-enable
the backing up of plugins again.
CURA-8313
This would've gone so wrong if we actually released 4.10 without this, since, as a string, 4.10 is 'smaller than' 4.6 (for example), because alphanumerical-order.
done as part of CURA-8269
Backups are synced with your account anyway. Backing up the plugins means that you
quickly reach the limit of the max size (250mb) that the backups allow.
CURA-8269
The server gives an error about this and we got complaints about it. As far as we know this can only happen when users mess with their profile folders. Still, it's good to not send -1. The original implementation of this is indeed very naive, but we don't have the resources to refactor that now.
For instance if the file name is too long for this file system, if the computer is running out of disk space or if there is a general failure to write here.
Fixes Sentry issue CURA-YQ.
Converted doxygen style comments to reStructuredText style in the files
found in Cura/cura/Backup directory recursively using the script
dox_2_rst.py (provided in the Uranium repo). Comments were manually
checked and changed if needed.
Prevent unpacking of possibly spoofed backups (as a last line of defence if other security has failed).
Zips with partially known content are a lot harder to spoof.
Thanks WhiteHats :-)
- Move AutoSave out of the plugins. It's a built-in module now.
- Add enable/disable saving data on CuraApplication.
- Avoid saving data in backup restore
