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 _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel