Re: Can unison better help with renamed hosts?

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