Closed jurgihub closed 7 years ago
Yes I agree, it's a bit of a problem. I guess originally my reasoning was that if there's any kind of error, we shouldn't assume anything - just notify the user, let them fix their backup script, and re-run it. But still, if the script reached that point the backup is done anyway (i.e. the script wasn't killed or anything) so it should be marked as done. This is fixed in d152279d301bf799c496d00d9b2aa706b46e88c6
Not sure how to reopen this issue, but log files are no longer being saved (or they are saved and immediately thereafter deleted) since I installed the updated script that fixed this issue.
@laurent22 This is no longer an issue.
Very specific setup, but no doubt the script does the same when using a different setup --> When using the script to do an SSH backup from MacOS to a Linux Gentoo server, backup.inprogress file is not removed, so the next backup tries to pick up where the previous one left.
The script does complain in the log about being unable to transfer a file, which in this case is a file exclusively owned by root (no user privileges). I do understand why the script does what it does, but in this case, it seems perfectly ok to flag the backup as "complete" (it's not like the backup was interrupted -- it's just about a file that can't be copied).