Am 13.02.20 um 10:16 schrieb Ulrich Sibiller:
Am 13.02.20 um 09:53 schrieb Ulrich Sibiller:
Sorry about that. One workaround might be to copy something to clipboard on the linux side and then on Windows again. Does that help? Do you think we could add some kind of workaround that "zaps" the clipboard(s) on both ends? Kind of like how you "zap" a heart with a defibrillator when it goes into ventricular fibrillation. While that wouldn't fix the issue, it would allow the user to continue without having to suspend and resume the session - plus we might be able to gather clipboard content info for a bugreport that way. I'm thinking of a "hexdump -C"-like output that gets stored to a file on each end and that the user could submit if there's nothing confidential in it. I deeply doubt that the clipboard CONTENT is responsible for the
On Thu, Feb 13, 2020 at 10:07 AM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote: problems. That's merely a problem in the workflow.
Are you sure? Some reports I received (though I'm still waiting for the final test results) hinted that special characters might be triggering it. Things outside the 7-Bit or 7-Bit+usual-Windows-codepage range. Things like accented characters or "unusual" whitespace (not a mere blank, \t, \r, or \n, of course).
My approach is rather adding a debug facility that can be enabled at runtime instead of compile time so that a user can enable it as needed.
A zapping keystroke could be implemented but I really consider as a temporary. I'd love to see the problems vanish altogether...
The thing is, if you log the content of the clipboard(s) on both ends *before* you zap, that info might help you with debugging this. Think of it as a "clipboard coredump".
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243