symless / synergy

Synergy lets you share one mouse and keyboard between multiple computers on Windows, macOS and Linux.
https://symless.com/synergy
GNU General Public License v2.0
10.3k stars 3.65k forks source link

Clipboard stops being shared after a while #95

Closed nbolton closed 9 years ago

nbolton commented 9 years ago

Imported issue:

Server Machine: Windows (has been xp, vista and now windows 7)
Client Machine: Linux RedHat AS4

Clipboard stops working from server to client, but it works the other way
around. The stuff i cut out in from the linux machine get stuck into the
clipboard it seems. This happens occasionally and only a restart of the
synergy server seems to help.

nbolton commented 9 years ago

This also seems to occur when Mac OS X is the client. Could this be related?

nbolton commented 9 years ago

I switched to 1.3.3 two weeks ago, and still see the same issues with clipboard not
working, every few hours I have to restart the server. I got 3 win2k systems. This
was reported for years on the 1.3.1 system, such as:

"http://sourceforge.net/tracker/index.php?func=detail&aid=1156841&group_id=59275&atid=490467":http://sourceforge.net/tracker/index.php?func=detail&aid=1156841&group_id=59275&atid=490467

"http://sourceforge.net/tracker/index.php?func=detail&aid=1458037&group_id=59275&atid=490467":http://sourceforge.net/tracker/index.php?func=detail&aid=1458037&group_id=59275&atid=490467

"http://sourceforge.net/tracker/index.php?func=detail&aid=2816211&group_id=59275&atid=490467":http://sourceforge.net/tracker/index.php?func=detail&aid=2816211&group_id=59275&atid=490467

"http://sourceforge.net/tracker/index.php?func=detail&aid=1600547&group_id=59275&atid=490467":http://sourceforge.net/tracker/index.php?func=detail&aid=1600547&group_id=59275&atid=490467

Since I'm windows only, I might try: "http://www.inputdirector.com/downloads.html":http://www.inputdirector.com/downloads.html

nbolton commented 9 years ago

Just wanted to add that my XP Pro SP3 server -> Ubuntu 9.04 client has the same
problem. Please let me know if there is any info I can provide to help.

nbolton commented 9 years ago

I've experienced this issue with 1.3.1 between two XP SP3 systems. The clipboard
works on each system; however, clipboard data transfer eventually ceases to function.
As previously noted, Synergy must be restarted on at least one system before
clipboard data transfer will function again. (I just installed 1.3.4 in hopes that
the issue is resolved, but I guess I'll find out soon enough.)

nbolton commented 9 years ago

Also experiencing this with server = Synergy 1.3.4 OSX 10.6.1, client = Synergy 1.3.4
Win7. Before upgrading to 1.3.4 (to resolve a different issue), it worked fine.

Note that after a downgrade to 1.3.1, copy/paste works again (and as it turned out, the
other issue didn't require 1.3.4 to fix anyway).

nbolton commented 9 years ago

Having same issue where clipboard data transfer stops after sometime. Server 1.3.4
win7, client 1.3.4 winxp.

nbolton commented 9 years ago

My too. server = 1.3.1, both simultaneous clients = 1.3.1
Ubuntu 9.04 32bit = server
Vista x64 = client
XP SP2 32bit = client

nbolton commented 9 years ago

I have noticed this as well. Also that content copied from an Ubuntu client appears
as kanji characters on a Windows server. I see this frequently when copying URIs out
of FireFox.

Pasting the content into gedit and copying, then pasting directly into notepad.exe
usually gets around the issue.

I think MS Office may have an impact, but I cannot be 100%% as the behaviour is pretty
random.

Synergy Server: Windows XPsp3, Synergy+ 1.3.4
Synergy Client: Ubuntu 9.04, Synergy+ 1.3.4

nbolton commented 9 years ago

Also having the same problem with two windows xp, 1.3.4

nbolton commented 9 years ago

Server: WinXP x86 | Synergy+ 1.3.4
Client: Fedora 11 x64 | Synergy+ 1.3.4

Clipboard fails daily when trying to move clipboard content from server to client. A
restart of the server solves this issue temporarily (for a few hours).

nbolton commented 9 years ago

This may or may not be related, but I suffered the same issue between VMware and
Host and RDP and Host. The culprit seems to be MS Office (especially Outlook). I
am not the only one in our office to have noticed MS Office killing the clipboard
sharing with other apps.

Does everyone you notices this run MS Office on their Windows machine?

My first soltuion was to create a shared folder on the VMWare/Synergy+, save
whatever I wanted into there and then to open it up wherever I needed it. A bit
clunky.

My current solution is to run MS Office in a virtualised environment on the Synergy+
client (should work running it on the Synergy+ host too). That way I only lose
clipboard-sharing with the virtualised environment.

Note: If running on the Synergy+ client, you'll need to use RDP to access the
virtual environment otherwise your keystrokes may get muxed up (just run it headless
and fire up a terminal services client).

I still suffer the kanji issue from time-to-time, but it's quite rare. The
gedit/notepad trick usually works. I put this down to Windows' poor handling of
Unicode (at least, it's poor IME; maybe things have improved).

Server: WinXP x86 | Synergy+ 1.3.4
Client: Ubuntu 9.190 x86| Synergy+ 1.3.4

nbolton commented 9 years ago

Same behaviour for 3-way-system (WinXP, Linux, WinXP) all Synergy+ 1.3.4. Sometimes
the clipboard still works for 2 screens but eventually no sharing is done after a while.

nbolton commented 9 years ago

I experience this issue with Solaris server and Windows client.
Per jasonirwin73, it does appear to be related to Outlook (2003 in my case) and its
clipboard. If I exit Outlook, the clipboard feature is very usable if not perfect.

When playing around with the Outlook clipboard visible, I did see an error "Item not
collected: Format not Supported" pop up which hallmarked moving from a mostly working
state to a mostly not working state.

I have not found a way to entirely disable the Outlook clipboard. Most of the help
revolves around disabling the pop ups.

It would still be preferable to have Synergy work well with the Office clipboard so
no deep modifications on Outlook are necessary.

nbolton commented 9 years ago

I have experienced this issue in some form since the pre-fork versions of synergy. It has clearly been the single most pesky issue with Synergy over the many years I have used it. If this issue is ever solved, it would be a true victory. I am running Synergy Server 1.4.1 on Windows 7, and Synergy Client 1.3.5 on Ubuntu 10.04. I have seen two flavors of the issue:

One is that clipboard data from the server will not paste to the client or is significantly delayed (like 30 seconds or more). It will appear that the paste operation is not working at all, but sometimes you will find that the data is finally pasted by the time you have looked away and come back.

The other flavor is that clipboard data captured from the client will not be updated on the server and a paste on the server will instead use old data previously stored in the clipboard.

In both cases, restarting the Synergy server usually clears up the problem for awhile (maybe a few hours or a day), but eventually the issue comes back. What further complicates this issue now is running the server as a Windows service. When run as a service, restarting no longer seems to fix the problem at all. In this situation, I have found that rebooting is the only way to get the clipboard back. It could just be something about the way the service is installed or being restarted; it doesn't make much sense, but it makes me consider moving back to running Synergy separately, just to have an easier time restarting it.

nbolton commented 9 years ago

I can copy from the client to the server fine, but rarely from the server to the client. Odd thing is, they're both the same version of synergy+, and they're both running on Arch Linux -- only difference is the client is i686 on my Eee PC, and the server's x86_64 on my desktop.

nbolton commented 9 years ago

Oh, I should add: on my desktop I'm using KDE+kwin, and on my Eee I'm using LXDE with Openbox. Not sure if that's a factor or not.

nbolton commented 9 years ago

I am seeing a possibly related issue on Mac OS X 10.6.4. Clipboard not shared at all between two identical systems, both running Mac OS X 10.6.4. This is 100%% reproducible with Synergy+ 1.3.4. This is certainly a regression since Synergy 1.3.1 (installed through Fink and using same configuration files) does not have this problem. Please let me know if you need any additional information.

nbolton commented 9 years ago

Just want to give a "me, too": server is running Windows 7 64-bit, client is Debian. Both are using official Synergy+ deliverables from this site.

nbolton commented 9 years ago

I too have experienced this issue since day once of using synergy.

I know what causes the issue. It's when you copy a non-text element to the clipboard (like files) in my case between two XP computers.

Hope that helps nailing down the issue.

nbolton commented 9 years ago

May have been fixed in r961 -- please check to see if this is fixed using the nightly builds.

nbolton commented 9 years ago

Ah, dammit, that was an osx fix.

nbolton commented 9 years ago

I want to add a detail too. I use the sharing of the clipboards in both ways (server --> client, client --> server). When I copy something to the clipboard of the server and then on the client copy something to the clipboard, the client machine will always use the clients clipboard for pasting, not the shared one (copying something on the server again afterwards has no effect on the clipboard on the client side). This is independent of time and absolutely reproducable.
My spec: latest beta version (had this issue also with stable one), Server: Win 7 x64, Client Win 7 x86.

nbolton commented 9 years ago

Me too. I have observed this issue:

Server: Windows 7 Pro x64 (1.4.8) Client: Mac OS X 10.7.4 (1.4.8)

I have trouble copying from the host machine (Windows) to the client (Mac). The other direction seems to be much more reliable.

There are some applications which are predisposed to have the issue more than others. As others have noticed, emails clients don't seem to work well. With Novell GroupWise I cannot copy the contents of any email from server to host, but I can copy certain interface text elements. Strangely, it seems that I can't copy anything from Firefox (13.0.1) HTML or plain-text, no matter where I copy it from, from host to client. However, anything I copy from Chrome (16.0), HTML or plain-text, seems to work. Similarly, anything I copy from Notepad works. So, my workaround is to copy content from the server first into Notepad, then copy again to the Mac client.

nbolton commented 9 years ago

Just got this with win7 server and Linux mint 13 client.

nbolton commented 9 years ago

To clarify, can't copy from Windows -> Linux, but can copy the opposite way.

nbolton commented 9 years ago

I confirm this happens with 1.4.10 windows 7 sever, ubuntu client. Can copy from the linux client to the windows machine, but not the other way around.

nbolton commented 9 years ago

Same as Danny King says. Please fix this!

nbolton commented 9 years ago

confirmed Windows 7 home premium -> ubuntu 12.04 does not work since upgrading to 1.4.10, must restart server on windows periodically.

nbolton commented 9 years ago

Confirmed as well with OS X as server and Win2008 as client. After a while, even restarting both synergys does not fix the problem.

nbolton commented 9 years ago

Confirmed with both client and server being Windows 7 Pro 64, client and server both running 1.4.10.

It stops working after a while server to client, but it seems to work client to server. I find occasionally I have to paste into notepad (I'm using N++), and then re-copy for it to work when pasting on the client from server. This includes Firefox's address bar, but the address bar from IE and Chrome work. Copying from the web page itself doesn't without the middle step of pasting into any text editor.

nbolton commented 9 years ago

Addendum: I don't have office running (though it is installed), but I do have the Google Calendar Sync running which occasionally interacts with an Outlook instance. At present I cannot see any office process running in my task manager.

nbolton commented 9 years ago

Me too: copying text from W7-64 server to OS X 10.7.5 client (all using Synergy 1.4.10 beta) doesn't work reliably (works at first but after a time stops working), but works consistently the other way (OS X client to W7-64 server). Thanks.

nbolton commented 9 years ago

I am running the 1.4.9 server on OS 10.6.8, and the client on Win 7.

The clipboard functionality dies with some regularity. It doesn't require copying anything more than text on either machine, just copying text from either machine to the other will sometimes kill it.

This didn't happen with 1.3.1.

nbolton commented 9 years ago

I've always had this issue as well on Windows XP. However, I have other clipboard utilities that occasionally have issues and the ones that seem to solve it have an option that "Reattaches to clipboard periodically". Could this perhaps be a solution for Synergy as well?

nbolton commented 9 years ago

All I see on this forum are people reporting the same issue. I have the exact same issue, the clipboard stops working after some time. Restarting Synergy works sometimes, sometimes it doesn't. It's extremely annoying. Is there no fix for this bug??

WIN 7 on both PC's. Synergy version 1.4.10. Do any Synergy developers monitor these forums as I don't see any replies other than people reporting the same issue?

nbolton commented 9 years ago

@Jane - If you're only using windows PCs, I suggest using Input director.

I've been using it for years now, as it doesn't suffer from the sticky-modifier problem like Synergy, and the clipboard is much more stable.

The only reason I have to be looking at Synergy again is to see if the annoyances have been fixed so I can add my macbook to the list of machines I control. Unfortunately it seems that people think adding an Android port is higher priority than getting the existing version working :(

nbolton commented 9 years ago

Just Reporting some Observations and small work arounds, nothing technical.

I use a multiBoot environment but most commonly Linking the machines together both Running Linux Mint and Synergy though on the machine running server I do sometimes still use Windows XP

I use my secondary machine running the Client to chat a lot and oftentimes exchange links and am occasionally told I shared that link before as of late ive gotten more vigilent about what links Im sharing and as with such made some new observations, at first when I noticed the incorrect links before sending them I would oftentimes go back to controlling the machine running Synergy server and re-copy the URL I was trying to paste, only to switch back to the client and have it paste the old one again, this back and forth could go on for several minutes without the pasting the most recently copied text and would oftentimes result in me using a work around or retyping it... however overtime I observed sometimes pasting a secondtime immediately after the first paste without copying from the source again will yield the correct clipboard result. So this can simply be corrected by pasting something, then highlighting and pasting over again immediately, which will paste the correct thing, however this dont work 100%% of the time sometimes synergy will insist on sending old clipboard data, fortunately there is a second work around, On most operating systems I run, the Simple Text editor(Notepad,Gedit,Pluma) consistently receives the correct clipboard results, so if your copying text from server to client and getting the old clipboard content consistently, you may open your simple text editor on the client, paste the correct clipboard content, and copy again before pasting at the target, this almost always works.

I don't know the technical reasons for those work arounds to work, but they just do, hopefully if this doesn't hint where the issue could be at least someone else experiencing the problem could use the work around.

nbolton commented 9 years ago

I remember researching this in the past and finding it's largely due to buggy behavior in Windows with the clipboard viewing. I'm assuming the Synergy client relies upon this API to receive notices when the clipboard has been updated, but due to bugs other applications can break this process so synergy stops receiving the vents.

One workaround mentioned here might be acceptable, while not perfect: http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/521183dc-7872-472e-8104-8c0d75b1bf53/ Basically re-register to receive these events on a regular basis instead of only once on startup. Every minute might be extreme, but anything would be better than always having to manually restart the Synergy service. There'd still be windows where the clipboard wouldn't sync, so this wouldn't be a complete solution, but a complete solution seems to require a fix to Windows, and Microsoft doesn't seem to have been interested in implementing this.

nbolton commented 9 years ago

Jody & anyone else, could you help us with steps to re-register? I wasn't able to find how to do this from the link.

Thanks

nbolton commented 9 years ago

James, does this help: http://www.delphidabbler.com/articles?article=9

This bug is really irritating. Even restarting the service doesn't seem to help.

nbolton commented 9 years ago

It's still present in the latest nightly build: 1.4.13-r1855 I'm running on a Windows client and Ubuntu server.

nbolton commented 9 years ago

James, it looks like an attempt was already made to fix it via this, but that there's issues with doing it. I was looking at the code and I saw this:

void
CMSWindowsScreen::fixClipboardViewer()
{
    // XXX -- disable this code for now.  somehow it can cause an infinite
    // recursion in the WM_DRAWCLIPBOARD handler.  either we're sending
    // the message to our own window or some window farther down the chain
    // forwards the message to our window or a window farther up the chain.
    // i'm not sure how that could happen.  the m_nextClipboardWindow = NULL
    // was not in the code that infinite loops and may fix the bug but i
    // doubt it.
/*
    ChangeClipboardChain(m_window, m_nextClipboardWindow);
    m_nextClipboardWindow = NULL;
    m_nextClipboardWindow = SetClipboardViewer(m_window);
*/
}

My guess is the infinite loop happens because this would put the window in the chain twice, but store the higher up position? You'd then get the event twice, and when the later one comes in it'd pop it back up to the higher position in the chain, triggering a loop? The ChangeClipboardChain is supposed to remove the window from the chain, but that seems to only happen if an application honors the WM_CHANGECBCHAIN event. I think this whole problem of lost clipboard happens because an app does not either send, or honor that request, and thus causes a break in the chain.

A more involved reset might be to create an entire new dummy window, insert that into the chain, then destroy the old window, removing it from the chain in the process. If the chain is still intact, no harm will happen as properly working apps would receive the events to alter the chain. However if there's a misbehaving app, Synergy would still get bumped to the top of the chain, and since the old window would be gone, there wouldn't be issues with the misbehaving app sending the message to Synergy a second time?

nbolton commented 9 years ago

I'm going to test this out tonight or in the next few days when I get a chance to try re-building Synergy, but i believe the following code in the fixClipboardViewer function would solve the infinite loop issue and let the workaround be safe:

ChangeClipboardChain(m_window, m_nextClipboardWindow);

destroyWindow(m_window);
m_window      = createWindow(m_class, "Synergy");
forceShowCursor();
LOG((CLOG_DEBUG "window is 0x%%08x", m_window));

m_nextClipboardWindow = NULL;
m_nextClipboardWindow = SetClipboardViewer(m_window);
nbolton commented 9 years ago

Hmm only problem with the above code is that I don't think there'll be a chance for our own event handler to handle the event from ChangeClipboardChain which means that could would make synergy itself a misbehaving app. My experience with Win32 API is a bit too limited and rusty so not sure how best to handle that.

nbolton commented 9 years ago

I also has the same problem with sharing clipboard. Server -> Linux Ubuntu 10.4 Client -> Windows 7

After while or loging out, login in again synergy clipboard stops working. It is no more sharing content of clipboards. Rest of synergy working correctly. After restarting synergy server it starts to work correctly with clipboard

nbolton commented 9 years ago

Fo what it's worth, I've had this issue between Windows and Linux/Mac machines for a long time, but I've always been able to work around it by passing the mouse rapidly back and forth between the two computers. One extra trip back to the source computer and back makes the clipboard sync up.

nbolton commented 9 years ago

I also have this issue. Using Debian Wheezy as server, and Windows 7 64bit as client. Clipboard from server (Debian) to client (Windows) works every single time. However, copying from the client (Windows) to the server (Debian) does not work at all. It used to work in some of the earlier versions, but even then it stopped working after a while (until the server and/or client was restarted).

Would be really nice to get this fixed...

nbolton commented 9 years ago

And just to add some more information; if I copy something to the clipboard on the server (Debian), let's say 'hello', and then go to the client (Windows) and copy something to the clipboard there, and head back to the server (Debian), the clipboard on the server is emptied (i.e. the content is ''). So synergy is doing something (since the clipboard is wiped clean), but obviously it's not doing what it should do (-:

nbolton commented 9 years ago

For VMware workstation version 10.0.1 the clipboard will work if you do Edit->Paste from file menu for VMWare. I also have had luck selecting paste from the applications context menu in the VM, just the CTRL+C/V function does not work from host to client. My host is Debian Wheezy and my client is Win7.

nbolton commented 9 years ago

Please analyse what the open-source "Ditto" clipboard manager (ditto-cp on sourceforge) does when you enable its "Ensure Ditto is always connected to the clipboard" option - it's the only program I've found that can do this right. The issue I found with other programs that monitor the clipboard disconnecting usually happened when I copied something in Excel. Note that Synergy should be able to handle other formats like that too (between Windows computers at least.) but main thing is that it shouldn't give up entirely.

Ditto's network sync feature does workaround this bug if you only have Windows running on the computers with Synergy, but of course that's no solution to the issue.