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

In my view, this is clearly a bug.

force=newer and force=older work based on mtime (modification time), as
it's also stated in the documentation. However, metadata changes do not
change mtime (they change ctime).

The bug is that the current code does not expect the mtime to be equal in
case of force=newer or force=older and so does not know how to treat a
metadata-only change. If mtime is equal then with current code the
propagation is always done from replica 2 to replica 1. I don't know why it
has been done like this, if there is some reasoning behind it or if it's
just an oversight.

I think the situation can be improved a little, if not completely fixed. If
mtimes are equal and only one of the replicas has (metadata only??) changes
then I think it is reasonable to propagate those changes. If mtimes are
equal and both of the replicas have changes then it is more tricky. We
could then compare ctime but not all filesystems/OS support it (or even lie
about it), and it could have been updated for any other reason, so not
really great to rely on ctime. The idea of the 'force' preference is that
there is automatic propagation in any case, so one of the replicas just has
to be picked "blindly" (as said, currently replica 2 is picked and
propagated to replica 1).

If some kind of agreement is reached on how it should work, and no
objections based on something breaking, then I'm ready to contribute an
improvement.



On Fri, 29 Sept 2023 at 10:27, Иван Николов <[email protected]> wrote:

> 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].
>

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