Unison improper behaviour on metadata change (chmod and chown) with force=newer.

Hello Unison users, 

TL; DR:
Unison behaves differently when synching metadata changes with option 
force=newer and without force=newer.

I am currently using unison 2.53.3 with ocaml 5.0.0 - built from source on 
a Rocky Linux 8 machine. 
My setup is as follows: 
Two Rocky 8 machines, synchronizing files remotely via SSH, with automatic 
conflict resolution and non-interactive mode. 
Unison works well when it comes to synchronizing files and propagating 
changes. 
The strange behaviour comes when changing the file's metadata, namely using 
chmod or chown. 

For example, if I create a file on machine 1, it gets properly copied over 
to machine 2. 
If I change the file's ownership or mode, it gets instantly synched back 
with the metadata from machine 2. This happens regardless if the file on 
machine 1 is with newer or older timestamp. 
If I change the file's ownership or mode on machine 2, then the change gets 
properly mirrored on machine 1 as well. Again, regardless of the timestamps 
and/or the size of the file. 

This happens all the same, even if the synchronization is local. I tested 
it with 2 local directories, /opt/dir1 and /opt/dir2.
If I make a change in the ownership or permissions of file1.txt in dir 1, 
it gets reverted back to the ones in dir2. If I change it in dir2, the 
change is reflected in dir1. 
Change does not get synchronized and is reverted:
[[root@hostname dir1]# ll
total 4
-rw-r--r-- 1 root root 85 Sep 29 09:51 file1.txt
[root@hostname dir1]# chmod 640 file1.txt
[root@hostname dir1]# ll
total 4
-rw-r----- 1 root root 85 Sep 29 09:51 file1.txt
[root@hostname dir1]# stat file1.txt
  File: file1.txt
  Size: 85              Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 8368565     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-09-29 09:51:16.365675505 +0000
Modify: 2023-09-29 09:51:04.955744336 +0000
Change: 2023-09-29 09:51:46.399126545 +0000
 Birth: 2023-09-29 09:51:04.955744336 +0000
[root@hostname dir1]# stat ../dir2/file1.txt
  File: ../dir2/file1.txt
  Size: 85              Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 8368511     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-09-29 09:51:16.367675668 +0000
Modify: 2023-09-29 09:51:04.955744000 +0000
Change: 2023-09-29 09:51:16.367675668 +0000
 Birth: 2023-09-29 09:51:16.367675668 +0000
[root@hostname dir1]#
Change gets synchronized:
[root@hostname dir2]# ll
total 4
-rw-r----- 1 root root 30 Sep 28 10:41 file1.txt
[root@hostname dir2]# chmod 644 file1.txt
[root@hostname dir2]# ll
total 4
-rw-r--r-- 1 root root 30 Sep 28 10:41 file1.txt
[root@hostname dir2]# ll ../dir1/file1.txt
-rw-r--r-- 1 root root 30 Sep 28 10:41 ../dir1/file1.txt
[root@hostname dir2]#

Here is my config file in its simplest form, with local synchronization.
###########
# Unison preferences file
# Roots of the synchronization
root = /opt/dir1
root = /opt/dir2

#Names and paths to ignore
ignore = Path .snapshots
ignore = Name .*.swp

#Settings
#Don't ask for changes with no conflicts
#auto = true
#Check only by size/modtime, if they are different, only then by hash
#fastcheck = true
#Automatically resolve conflicts in favor of newer timestamp
force = newer
#
group = true
log = true
logfile = /var/log/unison/unison_local.log
owner = true
#Watch for changes and repeat the synch after 3600 seconds, even if no 
changes detected.
repeat = 5
retry = 2
silent = true

numericids = true

#Try to sync times
times = true
###########
It is the same with and without the fs-watcher process.
Here is an example from the log file, with force=newer:
Unison 2.53.3 (ocaml 5.0.0) started propagating changes at 09:54:16.51 on 
29 Sep 2023
[BGN] Copying properties for file1.txt from /opt/dir2 to /opt/dir1
[END] Copying properties for file1.txt
Unison 2.53.3 (ocaml 5.0.0) finished propagating changes at 09:54:16.51 on 
29 Sep 2023, 0.000 s
Saving synchronizer state
Synchronization complete at 09:54:16  (1 item transferred, 0 skipped, 0 
failed)

If I remove the setting "force=newer" and use the exact same files without 
changes to them or the Modify times, it works as it is supposed to - it 
takes the change from /opt/dir1/file1.txt and applies it on 
/opt/dir2/file1.txt
Looking for changes
Reconciling changes
props    ---->            file1.txt
dir1         : changed props      modified on 2023-09-29 at  9:53:20  size 
94        rw-r--r-- user=0 group=0
dir2         : unchanged file     modified on 2023-09-29 at  9:53:20  size 
94        rw-r----- user=0 group=0

1 items will be synced, 0 skipped
0 B to be synced from dir1 to dir2
0 B to be synced from dir2 to dir1
Propagating updates
Unison 2.53.3 (ocaml 5.0.0) started propagating changes at 10:12:59.93 on 
29 Sep 2023
[BGN] Copying properties for file1.txt from /opt/dir1 to /opt/dir2
[END] Copying properties for file1.txt
Unison 2.53.3 (ocaml 5.0.0) finished propagating changes at 10:12:59.93 on 
29 Sep 2023, 0.000 s
Saving synchronizer state
Synchronization complete at 10:12:59  (1 item transferred, 0 skipped, 0 
failed) 

Please advise if I am missing something in the config or whether it is a 
bug.

Best regards,
Ivan Nikolov

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].