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

Tõivo Leedjärv <[email protected]> writes:

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

  [ force-newer trouble ]

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

As specified -- to force the newer -- it seems it is behaving correctly,
within the specification.

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

Sure, but the real bug is a conceptual one in "force newer".

  - Why is it ok to force newer in the first place?  What's the point?
    To me, this is a workaround for  changes happening on both sides,
    which is otherwise a "don't do that" situation.

  - What does newer really mean in the context of syncing?  Newer sort
    of means "last changed".  Viewed that way, ctime sort of applies,
    and perhaps the most recent of atime/ctime should be used.  However,
    if you do some sort of dump/restore, then you will change ctime even
    though you didn't make a logical change.

  - You could go further down the rabbit hole  and start to say that
    force newer applies if one mtime is greater, and that if mtimes are
    equal, then it is as if force=newer was not specified.

(I wrote the above before reading the rest of tyour message.)

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

Yes, with the caveat that we aren't really forcing newer any more.   We
are doing something else because we aren't in one of
  - no changes
  - one is newer

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

I'm assuming traditional behavior for ctime above, but indeed it's a
mess and we almost certainly just shouldn't go there.

I think my suggestion is consistent with yours, except that I don't see
it as reasonable to do any kind of force if the two mtimes are the same.
Without ctime (which I agree we don't have in general), we don't have a
sense of newer for properties.   So just acting like force wasn't
enabled seems safe, even if it might be annoying.


It might also be good to step back and see why people are using
force=newer.  I view it as a kludge to work around conceptually
incorrect setups, but that's almost certainly not fair.  Part of that is
that I am willing to design file layout to make sync make sense, rather
than the other way around.

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