This is a longstanding Known Issue with Bisync which I plan to fix in the near future. Essentially, this change slipped by undetected because it met all 3 of the following criteria:
- The change occurred while a bisync run was running. (The one from
2023/08/18 12:53:01to12:56:14in your logs.) - That bisync run made other changes to the same side where the undetected change occurred.
- The change was a modification of an existing file, not a create/delete/rename.
Lacking any 1 of these 3 would have prevented this (which is likely why you haven't encountered this more often). Had it not been for #2, Bisync would have re-used the initial listing snapshot for that Path instead of taking a new one at the end, and the change would therefore have been discovered on the next sync. And had it not been for #3, Bisync would have returned a critical error as a result of failing the --check-sync (still not ideal, but at least then you would have known about it.)
The reason that --check-sync didn't catch this is because it (currently) only compares filenames, not modtime, size, or hash. It can detect whether a file from one Path is missing on the other, but not whether both Paths have different versions of a file. (To be clear: I'm talking only about the --check-sync feature -- other parts of Bisync (such as the deltas) do indeed compare modtime.)
The reason that a --resync caught this while normal bisync runs did not is because normal bisync runs compare to the prior listing of the same side, while --resync compares to the current listing of the opposite side.
Until this is properly addressed in a future release, here are a few things I'd recommend:
-
Schedule your bisync runs less frequently -- you mentioned you're currently running it every 1 minute. If you changed it to every 10 minutes, the odds of this happening would decrease by approximately 10x. (FWIW, I run mine every 3 hours, and manually as needed.)
-
Use
--check-sync=false, as--check-syncis not foolproof anyway (as we've discussed) and without it, your bisyncs will be faster and less likely to end in a critical error. -
Supplement this with a periodic independent integrity
check, and corrective sync if diffs are found. This is documented in detail here, along with example commands. (This is especially important if using--check-sync=false.)
P.S. I fixed a bunch of other bisync bugs recently (but not this one yet) and added a few new features -- currently scheduled for v1.64. If you're interested in trying them early, they are available in the latest beta. Feedback is welcome 