Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Success message after failing to restore files #4051

Open
1 task done
fresheneesz opened this issue Jan 11, 2020 · 3 comments
Open
1 task done

Success message after failing to restore files #4051

fresheneesz opened this issue Jan 11, 2020 · 3 comments

Comments

@fresheneesz
Copy link

  • I have searched open and closed issues for duplicates.

Environment info

  • Duplicati version: 2.0.4.23_beta_2019-07-14
  • Operating system: Windows 10
  • Backend: local

Description

When restoring files, if the drive containing the backup is not connected, the restore finishes with a success message, even tho no files were actually restored. A separate warning pop up appears that says the backup doesn't exist, but since errors like that happen from time to time, I associate them with backup failures, and it wasn't clear that it was related to the restore failure.

Steps to reproduce

  1. Backup something to a drive
  2. Disconnect that drive
  3. Attempt to restore from that backup
  • Actual result:

Duplicati fails to restore any files and yet gives a success message.

  • Expected result:

No success message should appear, and instead a failure message should appear.

@fresheneesz
Copy link
Author

It seems like there are other situations where the messages given to the user in the main page are not accurate and preempted by a pop-up error. The error system really needs to be revamped to be more integrated with the actual UI. There should never be conflicting messages like "success" in the body of the page and "error" as a popup, or "validating restored files..." in one place and an "error" pop up that actually indicates that validation is no longer happening.

@seantempleton
Copy link
Contributor

Looks like this is ultimately caused by the Runner not rethrowing exceptions when tasks are run by the WorkerThread using commands that were added to the WorkerThread's queue because fromQueue is set to true.

This affects several operations performed by the server: restore, vacuum, verify, compact, repair and others.

Not throwing exceptions is clearly intentional which you can also see from the commit history (20f12f6) where fromQueue used to be called throwEx and was set to false.

@duplicatibot
Copy link

This issue has been mentioned on Duplicati. There might be relevant details there:

https://forum.duplicati.com/t/gpg-asymmetric-decryption-should-fail-but-does-not/17536/10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants