Prior to upgrading to XPP 9.3, my organization relied on multiple users sharing Restores (saved strings of text) between them, as described in the User Guide, Chapter 17-7. We have multiple users constantly working on the same projects. We have 100's of saved Restores (strings ranging from single words to entire paragraphs, or templates to be completed later).
After the upgrade to 9.3, none of our users can locate any others' saved strings, since XPP now runs in a strictly Windows environment without MKXServer.
This ability to share content was a critical part of our workflow which seems to no longer exist.
Does anyone using XPP 9.3 currently have multiple users (local or networked) that successfully access saved content located in their respective home folders (xz_profile/ed_savebufs)?
The developer and engineers seem to think it was a rarely used feature in the past, which is strange since it still has a dedicated chapter in the User Guide.
Lewis, I think you should insist with SDL support and engineering that this problem gets fixed ASAP You have some strong arguments to do so: - documentation says explicitly that this should be possible - you have a workflow that depends on this feature - there is no workaround possible The fact that not many customers do use this feature is beside the point if you ask me
Please know that XPP support and engineering have both been looking into this problem, but it's just not that "simple".
Sorry for the long post that follows, but there's no way to give a "quick" answer.
On the Windows platform, there's no obvious concept of "getting another user's home directory" like there is in the UNIX world.
Try searching on the web for something like "get another user's home directory on windows" and you'll see what I mean.
There's lots of stuff about getting a user's own home directory, but anything you'll find about getting another user's home directory are all based on "assumptions" (such as assuming that another user's home directory is "local" or resides under the same parent directory as the current user's %USERPROFILE% location) - and I will note that none of those are valid assumptions in the case of Lew and company's setup (and even in general that's not always a valid assumption).
The feature of being able to Restore another user's "save buffers" that Lew is referencing in the User Guide has just never really worked on the Windows platform (but you were always able to Restore save buffers that you had saved).
Why didn't SDL know that, and why doesn't the documentation state that? It's a very good question, and I'll try to give an explanation.
The fact that restore from another user did not work correctly was actually only pointed out to us fairly "recently" (this was well before Lew and company upgraded and at the time we didn't know it didn't work), and then we looked into it more deeply.
Now I'm going to get very technical: It turns out that the NutCracker framework used to support XPP running on Windows (up until XPP 9.2) did provide a UNIX-like getpwnam(other_username) routine that the XPP code was calling to get another user's home directory. There was nothing stated in the NutCracker man page for this routine (or any NutCracker documentation) that calling this function with another user's user name did not work.
Even worse (for us in engineering and QA when testing), the routine does not return an error when you do that but instead just returns an empty string (for the other user's home directory). That behavior "hid" from us that the feature was not working correctly.
The end result of what the code was actually doing, as far as we can determine, was that if a user was trying to restore from another user the end result was that XPP was looking for a "\.xz_profile\ed_savebufs\_sv_buffername" file. A user doing a Save (under the NutCracker framework) was saving to a %HOME%\.xz_profile\ed_savebufs\_sv_buffername" file. Note that a "terrible" side effect of where a "\.xz_profile\..." path is actually located on Windows depends on what is the CWD. That's all of what was discovered when we looked into it - a big mess.
Under "normal" circumstances, %HOME% (defined by NutCracker) would have had the same definition as %USERPROFILE%. However, this is not the setup for Lew and company.
About the same time as all of this, we were developing the XPP 9.2 release in which we went native-Windows and removed the NutCracker framework. One implication was that there was no longer any such thing as %HOME% - that's purely a UNIX variable and one that was part of having NutCracker (mimicking UNIX). We knew that on Windows the "restore from another user" was brain-dead anyway, so we attempted to fix it.
At that time the XPP code was changed for the "save buffers" stuff. A user's Save was changed to go to a %USERPROFILE%\.xz_profile\... location. For a user attempting to restore from another user, XPP calls the Windows GetProfilesDirectory() function [which typically returns the parent of %USERPROFILE%] and look for a GPD\otherusername\.xz_profile\... location. Doing that did make it all "work", with the limitation that it only worked for "local" users (logged into the same machine). That seemed like the "best" we could do (on Windows) and with that limitation it was working, so we didn't change the documentation (to say it didn't work).
Getting back to Lew and company and their situation. They had somehow, under the NutCracker framework, managed to be able to get the "restore from another user" working for them (they were manipulating the setting of %HOME% for users). We have been trying to "mimic" their setup on our own XPP 9.1 system, so that we can analyze how they managed to get it "working" in order to see how we might be able to "tweak" the XPP code to get it working again for them.
We have not been able to get there yet, but we are working on it.
I actually had the very same exact idea myself.
We'd still like to figure out how Lew and company got "something" working without having such a feature, but moving forward I'm sure we will want to implement something "new" so that this Save/Restore stuff can be made to work "sanely" on the Windows platform.
Thanks very much for all your good suggestions.