[OpenAFS-devel] 1.8 ubik/remote.c

[Benjamin Kaduk]

Hi Hartmut,

On Sun, Jan 21, 2018 at 10:38:27AM +0100, Hartmut Reuter wrote:
> In openafs 1.8 in ubik/remote.c you will end up with a database labeled "0.0" in
> the case we found out that the host the new database should come from is not the
> one we have the connection to. Keep the old version in tversion and epoch to
> restore it if actually we didn't get a new database.

Thanks for the report.  It seems it was stuck in mailman for a few
weeks though, so we didn't see it until today.

> --- remote.c.orig       2018-01-03 06:56:08.000000000 +0100
> +++ remote.c    2018-01-20 17:52:58.222611247 +0100
> @@ -460,6 +460,8 @@
>      /* send the file back to the requester */
>  
>      dbase = ubik_dbase;
> +    memcpy(&tversion, &dbase->version, sizeof(struct ubik_version));
> +    epoch = tversion.epoch;    /* Keep th current version to restore it later */
>      pbuffer[0] = '\0';
>  
>      if ((code = ubik_CheckAuth(rxcall))) {
> @@ -498,7 +500,7 @@
>  
>      offset = 0;
>      UBIK_VERSION_LOCK;
> -    epoch = tversion.epoch = 0;                /* start off by labelling
> in-transit db as invalid */
> +    tversion.epoch = 0;                /* start off by labelling in-transit db
> as invalid */
>      (*dbase->setlabel) (dbase, file, &tversion);       /* setlabel does sync */
>      snprintf(pbuffer, sizeof(pbuffer), "%s.DB%s%d.TMP",
>              ubik_dbase->pathName, (file<0)?"SYS":"",

I've attached a commit message to it and put it into gerrit at
https://gerrit.openafs.org/12905 , though my commit message suggests
that there will be additional edits made.

-Ben