<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
<pre wrap=""> We now autogenerate UUIDs for TM volumes and read/store the UUIDs from
a new config file afp_voluuids.conf, similar to what we do for the
The option "uuid" is gone.
Note that this implementation, but also afaict any implementation (at
least any implementation I'm willing to consider to implement mysel),
can not support individual UUIDs for TM volumes using $u in the path:
/Volumes/TM/$u "TM Backup per User" options:tm
All users will have distinct volumes, the volume name and more
important the announced UUID will be equal for all of em.
If I understand the change in direction described here (location of UUID
storage) it was occasioned by the realization that while there might need to
be just one Volume Name and one associated UUID, if the .volinfo approach was
used the same UUID would have to be stored in the directory associated with
each user. Determining that a UUID had already been issued to one user (so it
could be duplicated for another) would be a non-trivial task. Maintaining
those values in synchronization would also be unpleasant.
For those good reasons, you decided to store the the generated IDs (attached
to the volume name) in a file in the Netatalk configuration directory.
As I see it, the purpose of attaching a UUID is to help Time Machine maintain
its connection to a particular backup share when something changes that might
cause confusion. There are, four visible items that Time Machine must track
about a share used for backup: Server Name, Share Name, User Name and
UUIDs could be useful if either the server or share names changed, so long as
the UUID did not. The previous approach (.volinfo within the share's data
directory) had the virtue of traveling with the data it represented, whatever
its other faults.
I am aware of three cases:
1. The use of afp_voluuids.conf means that the admin who just changes an
existing server's name should not have to manage UUIDs at all.
2. The admin that changes the user (and Time Machine) visible name of a share
would need to edit the afp_voluuids.conf to update the share name.
3. The admin that moves the Time Machine shares to a new server would need to
move the appropriate entries from the afp_voluuids.conf file which represent
the moved volumes to the new server.
An important variant of case 1 comes about when two devices choose the same
Avahi typically uses the least significant part of the host name as the name
it advertises for all announcements. Certain low priced NAS products
(deficient in my view) name themselves with a hard coded value.
When a second such device is added on a lan, Avahi appends a hyphen and digit,
as in Foobar-2 to the requested name. This avoids a collision, but makes it
necessary for Time Machine to resolve the server with something like a UUID.
Since I have observed that some AFP clients can be picky about an exact match
between the Avahi advertised server name and the AFP server name (imposing
long timeouts before proceeding), I would suggest an option to retrieve the
server name from the deconflicted value that Avahi arrives at. It appears that
the function avahi_client_get_host_name might provide it. When in effect, this
option would insure synchronization between the AFP server name and the Avahi
Please teach me the difference of DNS-hostname, AFP-servername
$ hostname -s
$ cat /etc/netatalk/afpd.conf
"afpservername" -maccodepage MAC_JAPANESE
Avahi advertises the following names.
Is this implementation correct?
I suspect that you know about as much as I do, but my understanding is,
Avahi advertises the first, least significant part of the value
returned by hostname() or similar, unless explicitly overridden by a
value in avahi-daemon.conf.<br>
Thus, unless the AFP server is named using an identical rule, they may
not be the same.<br>
Avahi enforces a strict one address - one name policy (as do
traditional DNS A records, although more often violated).<br>
The underlying construct used to publish Bonjour information is just
like unicast DNS. A single A record defines the mapping between name
and IP address. Other records, emdedded in TXT records, share the name
but supply other information (like afpovertcp and adisk).<br>
Bonjour Browser puts those two bits together in an easily readable form
that tends to become confused over time with the underlying data
In any case, the machine name advertised by Avahi is not directly or
necessarily related to the AFP-servername. If the avahi name is
specified in the avahi-daemon.conf file, it may not be related to the
When using Bonjour to locate AFP servers (afpovertcp) the best
procedure to login to those servers would seem to be to resolve the
name to an address and talk to the AFP server at that address,
regardless of its AFP name.<br>
Under 10.5 the first choice in at least one case is to try to reach
that server by AFP name, wait for a timeout and retry as indicated
above (or so it appears from outside indications). I noticed this some
weeks ago and now I am uncertain whether this effected the traditional
server login UI, the Time Machine UI or both.<br>
This timeout (about 2 minutes) is avoided if the names are kept
strictly in sync.<br>
That issue does not occur under 10.6, indicating that something like
the procedure I recommended is being followed.<br>
So, that is all that I know about it (and a bit more).<br>