The patch provided in 124130 broke the Windows platform because it removed exported symbols names from the library. As I indicated back in January, if the functionality is going to be renamed but is identical to the old wire protocol, then stub functions need to be created for the old names. Those names can call the new names or return an error. It doesn't matter which.
I wasn't aware that such things could happen. So do I see this right? It's either - create new RPCs and let the old one's in place or - create new Stubs with the old names and replace the old ones Is that so?
There is the possibility that MPG and DESY will have to upgrade in any case. As part of OSD the behavior of the AFSFetchStatus SyncCounter was modified. Unfortunately, OSD is not the only project that has decided to modify this field. Sorting out who is going win the use of the SyncCounter is not up to OpenAFS. That needs to be decided by the members of the afs3-stds mailing list. Depending on how it gets decided someone is going to lose or perhaps everyone will lose. By losing I mean that their organization will be forced to upgrade.
Good point. Maybe we should strive to at least solve this conflict. After all, OpenAFS+OSD uses only a few bits for the protocol. As far as I can tell, the last volume update requires a whole 32-bit integer...
I'll discuss this with Hartmut on Wednesday. Hopefully we come up with something.
Regards Felix _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
