Using Bisync with Dropbox while someone adds a file into a watched folder causes a critical error and a resync to be needed. Is this an expected behavior?

[nielash (Niel)]

@dsisaac

If this is expected behavior, we are wondering how to make this work for our current workflow.

It is a known issue with the current version of bisync, and I'm working on a fix for it. Progress can be tracked in the following GitHub issues:

• Bisync fails when files are added during bisync operation · Issue #6841 · rclone/rclone · GitHub
• bisync: handle volatile changes consistently · Issue #5676 · rclone/rclone · GitHub

In the meantime, my recommendation is to use --check-sync=false and periodically do an independent integrity check as described here.

@dsisaac

It seems that running --resync for each of these commands is ill-adviside, but it is not clear to me why this would be the case. Can we run the command with --resync as a part of a recurring chron job?

The reason this is ill-advised is because --resync will only copy (not sync) each side to the other. Therefore, if you included --resync for every bisync run, it would never really be possible to delete a file -- the deleted file would always keep reappearing at the end of every run (because it's being copied from the other side where it still exists).

@dsisaac

Is there any way to force a resync run after an error like this is returned?

While you could write a short script to do this, I wouldn't recommend it, as there are scenarios where a --resync would make things worse instead of better. The path1 and path2 are out of sync error can mean that files were added during the run (as you noted), but it can also mean that files were deleted (or renamed) during the run. In this case, running a --resync next would cause these intentionally deleted files to reappear. What you'd want to do instead (at least, until the underlying issue is more properly fixed in a future version) is manually delete these files from both sides, and then run the --resync.

In general, bisync requires a --resync as a safety switch when it thinks a manual intervention from the user could be required before the next run to avoid data loss. So, running a --resync automatically, without first checking things out, would essentially bypass this safety feature.

(In the current stable version, bisync is admittedly a bit overzealous about requiring --resync in some scenarios where it's not truly needed. This is addressed in the latest beta by the new --resilient feature.)

@asdffdsa

i have never used rclone bisync, but perhaps this will spark an idea or solution.

rclone bisync --check-first

It's a good thought, but it will not help with this particular issue, because bisync has its own listing/delta engine that is not controlled by --check-first. The more relevant flag in this case is --check-sync.