Sync Behaviour Changes with "ignorearchives"

[Cintha16]

In order to prevent the “Non-Identical archives file causing Filesync failure”.
We have use “ignorearchives” option but after which we are facing behavior changes in Unison sync operation. We have also gone through the UNISON FAQ but didn’t the expected details.

Please help to explain the reason for this behavior change in file sync operation.
Unison Version: -
$unison -version
unison version 2.51.2 (ocaml 4.07.1)
Machine Details:-
$uname -a
Linux dl360x2430 3.10.0-693.21.1.el7.x86_64 #1 SMP Fri Feb 23 18:54:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Actual Problem:
Non-Identical archives file causing Filesync failure.
Fix option used from Unison for the Issue:
Additional argument “ignorearchives” from unison to “ignore existing archive files”.
-ignorearchives ignore existing archive files

New file creation -->No deviation
Modification of existing file -->No deviation
Permission changes -->No deviation
File delete --> Deviation ( deleted file is copied/synced again from the peer node)

Before Code change:
When file is deleted in one node then same file will be deleted in peer node during the sync.

[BGN] Deleting occ/var/performance/pm3gppXml/A20190212.0845-0850-ACTIVESESSION-JOB_ESA.xml from //dl360x2434//opt
[END] Deleting occ/var/performance/pm3gppXml/A20190212.0845-0850-ACTIVESESSION-JOB_ESA.xml

After Code change:
When file is deleted in one node then same file coped from peer node during the sync.

[BGN] Copying occ/var/performance/pm3gppXml/A20190212.0855-0900-REQUEST_HANDLING-JOB_ESA.xml from //dl360x2434//opt to /opt
[END] Updating file occ/var/log/Alarm.0.log
[END] Copying occ/var/performance/pm3gppXml/A20190212.0855-0900-REQUEST_HANDLING-JOB_ESA.xml

[Cintha16]

In order to prevent the “Non-Identical archives file causing Filesync failure”.
We have use “ignorearchives” option but after which we are facing behavior changes in Unison sync operation. We have also gone through the UNISON FAQ but didn’t the expected details.

@brabalan @bcpierce00 Please help to explain the reason for this behavior change in file sync operation.
Unison Version: -
$unison -version
unison version 2.51.2 (ocaml 4.07.1)
Machine Details:-
$uname -a
Linux dl360x2430 3.10.0-693.21.1.el7.x86_64 #1 SMP Fri Feb 23 18:54:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Actual Problem:
Non-Identical archives file causing Filesync failure.
Fix option used from Unison for the Issue:
Additional argument “ignorearchives” from unison to “ignore existing archive files”.
-ignorearchives ignore existing archive files

New file creation -->No deviation
Modification of existing file -->No deviation
Permission changes -->No deviation
File delete --> Deviation ( deleted file is copied/synced again from the peer node)

Before Code change:
When file is deleted in one node then same file will be deleted in peer node during the sync.

[BGN] Deleting occ/var/performance/pm3gppXml/A20190212.0845-0850-ACTIVESESSION-JOB_ESA.xml from //dl360x2434//opt
[END] Deleting occ/var/performance/pm3gppXml/A20190212.0845-0850-ACTIVESESSION-JOB_ESA.xml

After Code change:
When file is deleted in one node then same file coped from peer node during the sync.

[BGN] Copying occ/var/performance/pm3gppXml/A20190212.0855-0900-REQUEST_HANDLING-JOB_ESA.xml from //dl360x2434//opt to /opt
[END] Updating file occ/var/log/Alarm.0.log
[END] Copying occ/var/performance/pm3gppXml/A20190212.0855-0900-REQUEST_HANDLING-JOB_ESA.xml

@brabalan @bcpierce00

[bcpierce00]

Yes, the ignorearchives option should ideally only be used when the filesystems are already in a synchronized state. Its purpose is to allow one-time disaster recovery after the archives themselves have somehow gotten out of sync, and when using it you should exercise great care because (as you noticed) it will change unison's behavior. Specifically, it will make unison behave as though the previous "last synchronized state" of both filesystems was completely empty.