Re: Can unison better help with renamed hosts?

On Tue, 23 Apr 2024 at 14:18, 'Mario Emmenlauer' via unison-users
<[email protected]> wrote:
>
> Can you explain what you mean by "guessing"? I assume that unison does
> know the host name it expects (from the archive), and does know the host
> name it actually found instead (the one it would put into a new archive,
> if this where a first time sync). So I was under the (naiive) impression
> that unison holds all the information I would need, if only it was
> displayed :( Or am I on the wrong track here?

There's already some good discussion going on, but to take a step back:

- Unison doesn't know which host you mean, so it couldn't possibly
  relate the expected name and actual name.
- Unison gets each host's name by gethostname(3), which can be
  overridden by env var UNISONLOCALHOSTNAME on both server and client,
  and also by pref "clientHostName" on client only.
- There is a debug preference "showarchive" that will show the names
  Unison has detected.
- While the hostname-based ID seems to mostly work well, it quickly
  becomes frustrating when the name changes often (as is the case for
  Mario) or permanently (as is the case for Greg).

How to improve?

- There was already a mention about uuid, but I'd make the suggestion
  even simpler:
    let the user provide the ID (on command line or in the profile) for
    the server. Basically, adding a "serverName" preference which will
    override all of the abovementioned mechanisms, just like there is
    one already for the client. If you as a user then mess up and
    connect to the wrong host, that's on you. But the wrong server will
    likely not have the archive for this name, so most likely you'd get
    the big warning.
- Finally, there should be a way to rename the archives without having
  to drag 'rootalias' or UNISONLOCALHOSTNAME around forever.

Together with the proposed solution, I'd also rename the
"clientHostName" preference to just "clientName". Both the
"clientName" and "serverName" can be completely arbitrary, so don't
need to refer to the "host" part, even though they'd effectively
override the hostname. This way, you could even have differently named
"instances" on the same host. Can't see any purpose for that besides
debugging, yet, but you never know.

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