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

I don’t know of any good reason for the current behavior — it sounds like a
missed case. The proposed change makes sense to me.

     Benjamin

On Fri, Sep 29, 2023 at 7:14 AM Tõivo Leedjärv <[email protected]> wrote:

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