4

I've set up a custom automated sync between 2 folders (in OSX) with unison with the following line:

unison folder1 folder2 -batch -debug update+

Which worked fine until I encountered:

Synchronization complete at 12:01:44  (0 item transferred, 1 skipped, 0 failed)
  skipped: example.txt (contents changed on both sides)

I'd like the command to automatically sync the most recent version. Looking in the options:

$ unison -help | grep conflict
 -auto              automatically accept default (nonconflicting) actions
 -copyonconflict    keep copies of conflicting files
 -prefer xxx        choose this replica's version for conflicting changes

.. which suggests the only way to resolve is with -prefer, but I may be missing something. Is it possible to specify version by time-stamp?

EDIT: All relevant bits of the sync report:

[update+]   Unchanged file
[update+] buildUpdateChildren(handleChild): example.txt
[update] buildUpdateRec: /path/to/folder1/example.txt
[update] checkContentsChange: archStamp is inode (3373366) / info.inode (3373748) / times: 1433242394.000000 = 1433242527.000000... false / lengths: 110602 - 110611
[update+]   Double-check possibly updated file
[update]   archive digest = (29c46acff8e661513ec7487bc0069c2b,)   current digest = (cdc82c2519076f9e52486b1c881e179d,)

[update+]   Unchanged file
[update+] buildUpdateChildren(handleChild): example.txt
[update] buildUpdateRec: /path/to/folder2/example.txt
[update] checkContentsChange: archStamp is inode (3373726) / info.inode (3373746) / times: 1433242452.000000 = 1433242515.000000... false / lengths: 110602 - 109400
[update+]   Double-check possibly updated file
[update]   archive digest = (29c46acff8e661513ec7487bc0069c2b,)   current digest = (e12ef45f692808d50989ca4b08d8c27f,)

changed  <-?-> changed    example.txt

Synchronization complete at 12:23:37  (0 item transferred, 1 skipped, 0 failed)
  skipped: example.txt (contents changed on both sides)
Improve this question
  • 1
    I can understand why time stamps are not offered to resolve conflicts: if a trivial change on one system is made after a significant change on the other, you would not want to keep the later version. – AFH Jun 2 '15 at 11:41
  • Fair point. But you'd think there might be some way of discerning substantive changes such as e.g. changing the number of lines in a file. – geotheory Jun 2 '15 at 11:57
  • Except that text files are in a minority these days, with media and office files predominating, and these are nearly all binary. In any case a substantial text edit may not change the number of lines in a file, hence the use of "content digests" (probably CRC32-derived), where the least change in the source file will produce a completely unrelated digest. Without keeping a third copy of the directories after synchronisation, it is impossible to determine which changes were minor after both files have been updated. – AFH Jun 2 '15 at 13:07
  • Drat and fiddlesticks – geotheory Jun 2 '15 at 14:12
3

I've given up on time stamp and settled for prioritising one version by adding the argument

-prefer /path/to/folder1

which resolves the conflicts.

Improve this answer
0

I think this will help. As Changes in Version 2.48.4:

Added a "copyonconflict" preference, to make a copy of files that would otherwise be overwritten or deleted in case of conflicting changes. (This makes it possible to automatically resolve conflicts in a fairly safe way when synchronizing continuously, in combination with the "repeat = watch" and "prefer = newer" preferences.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.