Before posting, and to avoid disappointment, please read the following:

  • This forum is not for 2BrightSparks to provide technical support. It's primarily for users to help other users. Do not expect 2BrightSparks to answer any question posted to this forum.
  • If you find a bug in any of our software, please submit a support ticket. It does not matter if you are using our freeware, a beta version or you haven't yet purchased the software. We want to know about any and all bugs so we can fix them as soon as possible. We usually need more information and details from you to reproduce bugs and that is better done via a support ticket and not this forum.

better error handling please

For technical support visit https://support.2brightsparks.com/
Post Reply
Statick
Newbie
Newbie
Posts: 2
Joined: Sun Dec 22, 2019 3:38 pm

better error handling please

Post by Statick »

I've tried a number of different sync programs and while SyncBack seems to be the best all round, it's unfortunately no good at all when it comes to handling file system errors. The current error handling system seems to just be "log it and move on" which actually isn't handling errors at all, it's just noting them down for a human to manually handle later.

I'm syncing to a windows network share over VPN so it's a regular windows network file copy, but over slow internet speeds and it occasionally generates transient "access denied" errors. I can't do anything about these. These errors always go away if you retry them, but SBSE does not do this. They are just logged and that's it, and if you're using the fast backup system (which is necessary due to network speeds) then on the next run, these failures go into the fast backup database as needing to be copied in full, which means lots of wasteful data copying - which can again fail for the same transient errors.

I can never get my backup to be 100% complete because of this, because scanning the destination will always result in a large number of random files and folders that failed with an error, and the only thing I can do is another full scan which results in another large number of random failures, or copy a large amount of data needlessly, some of which will also fail for the same errors and so a full scan is still needed to pick up the pieces after.

I've been using Free File Sync as well, which isn't particularly good software, but it does handle errors well - it has the option to retry any errors (both in analysis and in copy) X times with X second delay, and this solves all of my problems 100%. It is missing many other features that SBSE has, so I can't really use it. Yet it handles errors perfectly, and it's completely free! Currently I have to do a full scan and copy using Free File Sync after using SBSE, in order to be certain that I've actually achieved 100%.

SBSE would be absolutely fantastic if it could handle errors automatically - simply the option to "retry errors X times after X second delay" in the profile would be ideal, should be simple to implement, and it would make this genuinely useful and good software.

What would be even better is if any files that are still failed after X attempts during analysis, if you're running a fast backup, then these should go back into the fast backup database to be scanned again. They shouldn't go into the database to be copied in full, as they currently do - they have failed to be analysed, so on the next run they again need to again be analysed, not copied in full
rustleg
Enthusiastic
Enthusiastic
Posts: 10
Joined: Tue Feb 21, 2006 10:32 am

Re: better error handling please

Post by rustleg »

I realise this post is 2 years old but I agree with the original poster. I use Dropbox to back up files which includes the zip file I am trying to create with Syncback. Sometimes Syncback fails with error "Compression error: Cannot open zip file. (503)". Other times this error does not occur so I can only assume it's due to Dropbox trying to sync it. A simple retry option "retry X times after X second delay" as the poster suggests would solve the problem. I have had this issue for some time but was assuming Syncback developers would see the issue and fix it.

The result is that it breaks my backup chain and leaves the latest versions of files at risk.
christkenddy
Newbie
Newbie
Posts: 6
Joined: Sun Apr 17, 2022 10:26 am

Re: better error handling please

Post by christkenddy »

rustleg wrote:
Wed Apr 20, 2022 7:35 am
I realise this post is 2 years old but I agree with the original poster. I use Dropbox to back up files which includes the zip file I am trying to create with Syncback. Sometimes Syncback fails with error "Compression error: Cannot open zip file. (503)". Other times this error does not occur so I can only assume it's due to Dropbox trying to sync it. A simple retry option "retry X times after X second delay" as the poster suggests would solve the problem. I have had this issue for some time but was assuming Syncback developers would see the issue and fix it. [url]https://mini-militia.com[/url

The result is that it breaks my backup chain and leaves the latest versions of files at risk.
I think you should check this out.

https://help.2brightsparks.com/support/ ... p-file-503
rustleg
Enthusiastic
Enthusiastic
Posts: 10
Joined: Tue Feb 21, 2006 10:32 am

Re: better error handling please

Post by rustleg »

christkenddy wrote:
Sun Apr 24, 2022 8:14 am

I think you should check this out.

https://help.2brightsparks.com/support/ ... p-file-503
Of course I already read this which is why I said the problem is very likely because Dropbox is trying to sync it, i.e. the file is locked by Dropbox.

The article you quote gives 4 reasons. The fact that most times the error doesn't occur means reasons 1 and 2 are not the explanation. And I have no reason to suppose that there is a bad sector which is the 4th possibility. So it boils down to a lock on the file. My problem is essentially the same as the original poster's. Dropbox doesn't know SB is about to try to access the file, so there's no way to stop the error occuring. The simple solution is to get SB to abort and retry after a delay, ideally retry up to x times after a delay of x seconds as the original poster suggested, the x's to be specified in the setup.

I'm running this on an automatic daily schedule for backup, which is the whole point of using Syncback. I don't expect to have to check every day that the backup has been done.
Post Reply