Minkata is back open for testing! Age State problem fixed.

[rarified]

Is there a patch available, or does the fix need more testing before a patch can be released?

Thanks.

I think the fix has shown to work, but I have not yet prepared a commit. I need to go through the diffs and tease out the code changes for this bug, as well as make up the changes to the autoconf templates to add a default gcc option to compile and link steps.

_R

[rarified]

Is there a patch available, or does the fix need more testing before a patch can be released?

Thanks.

The review on Fisheye is up (for this change, others coming). I'll push the changes to the Minkata fork MOSS-minkata on BitBucket in a little while.

[Edit: The BitBucket Pull Request is now up for review as well. At some point in the future I hope to link FE and BB review data]

_R

[cjkelly1]

readdir_r() was removed in "changeset 44 - 0027fc4da658" because it is deprecated in glibc. Since there is no way to know when deprecated will turn into removed, I would not recommend adding it back in.

[rarified]

readdir_r() was removed in "changeset 44 - 0027fc4da658" because it is deprecated in glibc. Since there is no way to know when deprecated will turn into removed, I would not recommend adding it back in.

I need to look into this. I’m seeing the glibc mention about deprecation, but a POSIX-1.2008 reference still declares readdir() thread-unsafe even with serialized access to the DIR* stream. Perhaps I can find a preprocessor cue to detect older environments where it is unsafe.

_R

[edit: the recent update to the POSIX specification does not mention the elimination of the readdir_r() API. It also still says that readdir() need not be thread safe. I wonder if glibc will retain the entry point as a shim around the base implementation of readdir()]

[cjkelly1]

It would seem that the root of the problem is that NAME_MAX is not guaranteed to be defined on all systems, and evidently readdir_r() assumes it is.

[rarified]

True, a constant value no longer was sufficient.

I believe the use of pathconf(..., _PC_NAME_MAX) was a reasonable (and intended) portable answer to that problem. The only platform I found so far that didn’t support it was WIN32.

_R

[Christian Walther]

I can log in fine with my avatar “CW 78” (170127), but with “Christian Walther” (3032) I get “UNTRANSLATED: SetActivePlayer failed: Vault Node Not Found” after “Preparing to Link”. According to the logs, the missing vault node is 2389 and should be a PLRINFO (child of PLRINFOLIST 3034, my buddy list). Any idea what happened there, did something go wrong in the vault restore?

[rarified]

Hmmm, not that I saw. But the vault went through a number of dump/restore cycles during the problem period.

It’s early here and I haven’t been up to my desk, but will look at that DB entry when I get there. And I still have the past dumps so if it is an individual record I can restore I will.

_R

[rarified]

... According to the logs, the missing vault node is 2389 and should be a PLRINFO (child of PLRINFOLIST 3034, my buddy list)...

I'm not sure what happened, but I found the playerinfo node in a January 2017 dump. It was one of my avatars.

I've restored it and checked the linkages to other nodes (at the first depth level). Try accessing that avatar again and let me know.

_R

[Christian Walther]

Works, thanks!