Wrong exit status when backup is canceled

stepping-stone / sepiola

Sepiola - Online Backup Client

http://www.sepiola.org/

GNU General Public License v2.0

5 stars 2 forks source link

Wrong exit status when backup is canceled #4

Open paescuj opened 11 years ago

paescuj commented 11 years ago

When the backup-process is aborted by the user the exit status is failed, but should be canceled. The same happens when the restore-process is aborted by the user.

rsync exited with exitCode 20 (rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(244) [sender=2.6.9]

Update:

Pressing "Cancel" button should be recognized by Sepiola and an appropriate, user-friendly message like "Backup/Restore process was aborted by user" should overlap rsync error output in addition to an aborted-by-user status on the top of the dialog box and in the overview.
The exit code when killing rsync process (f.e. by command line) without pressing "Cancel" button should also be interpreted by Sepiola and an appropriate, user-friendly message like "Backup/restore process (rsync) received a termination signal for unknown reason" should overlap rsync error ouput and therefore result with a failed status on the top of the dialog box and in the overview.

dev-zero commented 11 years ago

We can't control the exit status of rsync, just the interpretation of it by Sepiola.

meichenberger commented 11 years ago

The enhancement is valid. When a user aborts manually from Sepiola (for example by clicking Quit, not killing the process on the command line), we have the necessary Information to be able to inform the user, that the last backup was cancelled.

dev-zero commented 11 years ago

Where does it say that the backup failed when it was manually aborted:

Do you get a dialog box stating that it failed while you aborted it?
Or is it listed as failed in the overview (instead of aborted-by-user)?
Or both?
What about the XML Sepiola writes to the server? Should it try to upload it after a user cancelled the backup, possibly with a respective flag?

paescuj commented 11 years ago

Sorry, I did not express myself very well. I thought the interpretation of the exit status by Sepiola. I noticed the "failed"-status on the top of the dialog box and also in the overview.

meichenberger commented 11 years ago

The answer is:

The backup is listed as failed in the overview (instead of aborted-by-user), so no dialog box.

To you other questions: What about the XML Sepiola writes to the server? Should it try to upload it after a user cancelled the backup, possibly with a respective flag?

Good questions: * Minimal: Do nothing. * Nice: At least upload the xml with the backup information, telling us, that the user aborted the backup. Therefore the schedule warning script could be updated accordingly. \ Great: Tell the user, that by aborting the running backup, information will be missing and if the users wants to recalculate these missing files and upload them before aborting (like the permission file).

paescuj commented 11 years ago

The error output on the right-hand side is as expected. But on the top of this dialog box the summary of the status should be aborted-by-user (not failed). sepiola-sh1

dev-zero commented 8 years ago

Even though the bug seems rsync related, it actually is not: The user may cancel the backup/restore during any operation (ACL-list generation/restoration, etc.). All such errors are handled rather poorly and care has to be taken to solve this issue in a more general sense rather than for rsync only.