Avoiding bisync conflicts: No winner can be determined

Help and Support
1

What is the problem you are having with rclone?

I have set conflict-resolve to newer to prevent the many conflict files I was encountering when using VS Code but there were some generated today.

In VS I I used 'Replace in files' to edit the groupid in batch, which is found in multiple pom.xml and other files across the project. At some point not long after changing the groupid I observed one of the pom.xml files turn into two, pom.xml.conflict1 and pom.xml.conflict 2, one which has the original groupid tag and the other the new.

Before I opened my project I confirmed there were no errors generated from the most recent run of the command below, which executes every 5 minutes:

rclone bisync "idrive-sync-crypt:/" "/home/salty/sync/" --check-access --fast-list --verbose --filter-from=/home/salty/.config/rclone/filters --links --recover --ignore-checksum --error-on-no-transfer --conflict-resolve newer --resilient

Run the command 'rclone version' and share the full output of the command.

rclone v1.67.0-beta.8014.8bc00b6ad.s3-fix-405-error
- os/version: ubuntu 23.10 (64 bit)
- os/kernel: 6.5.0-21-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.22.4
- go/linking: static
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

IDrive e2.

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[idrive-sync]
type = s3
provider = IDrive
access_key_id = XXX
secret_access_key = XXX
acl = private
endpoint = x3k6.ie.idrivee2-50.com
bucket_acl = private
no_check_bucket = true
server_side_encryption = aws:kms

[idrive-sync-crypt]
type = crypt
remote = idrive-sync:sync
password = XXX
password2 = XXX
filename_encoding = base32768

A log from the command that you were trying to run with the -vv flag

Sample of conflicts throughout the project:

2024/06/17 17:04:26 NOTICE: - WARNING           New or changed in both paths                - code/mod1234/lab3/lifeco-jms/task1/pom.xml
2024/06/17 17:04:26 INFO  : code/mod1234/lab3/lifeco-jms/task1/pom.xml: Winner cannot be determined as times are equal. Path1: 2024-04-24 18:09:56.301656 +0100 IST, Path2: 2024-04-24 18:09:56.301656 +0100 IST, Difference: 0s
2024/06/17 17:04:26 INFO  : code/mod1234/lab3/lifeco-jms/task1/pom.xml: A winner could not be determined.
2024/06/17 17:04:26 NOTICE: - Path1             Renaming Path1 copy                         - idrive-sync-crypt:/code/mod1234/lab3/lifeco-jms/task1/pom.xml.conflict1
2024/06/17 17:04:27 INFO  : code/mod1234/lab3/lifeco-jms/task1/pom.xml: Copied (server-side copy) to: code/mod1234/lab3/lifeco-jms/task1/pom.xml.conflict1
2024/06/17 17:04:27 INFO  : code/mod1234/lab3/lifeco-jms/task1/pom.xml: Deleted
2024/06/17 17:04:27 NOTICE: - Path1             Queue copy to Path2                         - local{b6816}:/home/salty/sync/code/mod1234/lab3/lifeco-jms/task1/pom.xml.conflict1
2024/06/17 17:04:27 NOTICE: - Path2             Renaming Path2 copy                         - local{b6816}:/home/salty/sync/code/mod1234/lab3/lifeco-jms/task1/pom.xml.conflict2
2024/06/17 17:04:27 INFO  : code/mod1234/lab3/lifeco-jms/task1/pom.xml: Moved (server-side) to: code/mod1234/lab3/lifeco-jms/task1/pom.xml.conflict2
2024/06/17 17:04:27 NOTICE: - Path2             Queue copy to Path1                         - idrive-sync-crypt:/code/mod1234/lab3/lifeco-jms/task1/pom.xml.conflict2

...
2024/06/17 17:04:30 INFO  : code/mod1234/lab3/lifeco-jms/task1/pom.xml.conflict2: Copied (new)
2024/06/17 17:04:31 INFO  : - Path1             Do queued copies to                         - Path2
2024/06/17 17:04:34 INFO  : code/mod1234/lab3/lifeco-jms/task1/pom.xml.conflict1: Copied (new)

The conflicts that were happening before I added an argument to deal with them were frequent enough not to just be caused by the string replacement, so they may very well be negated by the argument, but it would be great to be able to refactor without this issue.

How did a single host generate this conflict in the first place, and how can I prevent this or handle it better in future?

2

v1.67.0 has been released as stable. might want to test with that.

1 Like
3

It looks like "Replace in files" is editing the files' contents without changing the modtime. Accordingly, bisync knows that the two files are different, but cannot tell which one is "newer".

I wonder if for your particular use case, you might prefer --conflict-resolve path2 instead of newer. (In other words, always prefer the local version, not the idrive/crypt version, in the event of a conflict.)

1 Like
4

Thanks, I had held off updating to 1.67 because I was only recently able to confirm nielash's patch fixed an issue, but on your reply I checked on this and I can see it was already merged into main.

After updating, I restored the original state of the project, and despite my best efforts, I have not been able to reproduce the issue. I tried running the replace at different intervals during the rclone check, and I also did it during a scan and as soon as files were queued to be copied reverted the replace, which did generate a critical error prompting resync but recover handled this perfectly on the next trigger of the script.

5

It is strange, because although the log was showing the mod time was the same for one of the files I looked at, when I checked in terminal I saw one of the conflict files had a mod time of several weeks ago (I assume conflict1), while the other matched the scan. Nearly posted this and should have but I thought what was happening was normal and I had to adapt how I was using rclone.

Also curious is that as per my last, after updating no such issue is occurring today, unless I experienced a bug that was fixed in 1.67?

Good to know about --conflict-resolve path2, thanks, and I will have a think about how that may play on current setup of just syncing two computers via cloud. Though I am unsure how it might apply to yesterday, as the issue occurred on my laptop, which I confirmed had synced without any changes to apply and without issue minutes before opening VS, and the desktop was not on since the day before so should not have been a factor in the conflict arising.

6

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.