Re: Can unison better help with renamed hosts?

This discussion is getting off-topic for the -users list. Is it worth
continuing on the -hackers list or are we reaching a conclusion of
"without a good reason, don't touch what's not broken"?

On Wed, 24 Apr 2024 at 17:01, Greg Troxel <[email protected]> wrote:
>
> Tõivo Leedjärv <[email protected]> writes:
>
> > On Wed, 24 Apr 2024 at 15:34, Greg Troxel <[email protected]> wrote:
> >>
> >> If what we are doing is saying that it should be a hostname, and we are
> >> remediating that changing, that's different from saying that it is an
> >> arbitrary string that should be unique and unchanging, and that we
> >> default to hostname because it traditionally had those properties.
> >
> > Now that I think about it some more, we could actually just skip the
> > whole client-server part of this and use the same ID on both. It would
> > then become the ID for the "sync setup" more than anything else. But
>
> Sure, but that id needs to use state from both sides.  Basically I think
> that dissociating control state from how it is used is asking for
> trouble.  And we do have an id for the sync setup: it's the hash of both
> peer ids.
>
> > I think we've now established that the problem was in fact the client
> > getting different names. We can expect this to happen much more rarely
> > on the server side, though you can just as well sync between two
> > laptops. If it's very rare on the server side then the current tools
> > suffice, I think.
>
> sure
>
> >>   permanent rename is still messy
> >>
> >> which leads me to
> >>
> >>   we should generate a per-host identifier which can bootstrap from a
> >>   non-dynamic dhcp name and store it, perhaps with some random bits to
> >>   avoid collissions
> >>
> >>   we should just use that identifier
> >
> > I was thinking in that direction too. That could be a rather nice
> > solution with just one (maybe tiny) caveat. If the stored identifier
> > is deleted then (unless the same id is re-generated) it would force
> > full rescan even if the archive files were not deleted. Basically,
> > deleting either the archive file or the stored id file will have the
> > same result from user's perspective. Maybe that is fair?
>
> I think it's fine to have to rescan if things change, as long as those
> things aren't expected to change often.
>
> However, it strikes me that having ~/.unison have state about a replica
> reached by a pathname on that system is also dissociated state.
>
> An example: I do backups (not involving unison at all) to external
> disks.  Because I was raised UNIX, I mount them on /mnt.  If I were
> doing unison, there'd be records in ~/.unison about /mnt/foo, but when I
> put in different disks, there are different bits.  That's me, but this
> seems easy to happen.
>
> So really, state about a replica belongs in /path/to/replica/.unison
> (which is *never* synced and cannot be) or someplace, all of identifier,
> ar, fp, lk.
>
> It's certainly fair to configure identifier in .unison and use that as the
> initial value for replica identifier.
>
> And those per-replica identifiers need to be unique.  It can be a UUID
> per replica, or it can be a "clientidentifier" plus a replica name.
> Then we need to tell people not to rsync replicas unless they intend to
> move them!

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