Re: Can unison better help with renamed hosts?

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
then again, now that Mario's issue is solved, we really don't need
this complexity. A one-time rename function would still be good to
have, though.

> So:
>
>   it works but it is too hard

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.

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

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