Synergy

Issue Tracker (powered by SPIT)

Bug #104 - Clipboard stops being shared after a while

Status:
Accepted
Priority:
Normal
Assignee:
None
Category:
None
Target:
None
Found:
None
Created by:
Created on:
29 Jun 2009
Updated by:
Updated on:
25 Jul 2012 01:16
Platform:
Windows
Google ID:
gc-95
Redmine ID:
134

  • Related to: Bug #76 - Clipboard sharing (copy and paste) with OS X does not work
  • Related to: Bug #319 - Clipboard does not work when Mac OSX is a server
  • Related to: Bug #1230 - Clipboard stops working after a while
  • Related to: Bug #2369 - Clipboard stops working on XP
  • Related to: Bug #2419 - Copy/Paste Windows will stop working
  • Related to: Bug #3046 - Copy/paste stops working after using VNC
  • Duplicated by: Support #3333 - Clipboard stops working

Google user: aidin.fanni

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.


#1

3 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk

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


#2

7 Jul 2009: Issue Importer wrote a comment.

Google user: mynova

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&groupid=59275&atid=490467":http://sourceforge.net/tracker/index.php?func=detail&aid=1156841&groupid=59275&atid=490467

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

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

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

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


13 Jul 2009: Issue Importer changed Status.

New Accepted


#3

13 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk


16 Jul 2009: Issue Importer changed Target.

?


#4

16 Jul 2009: Issue Importer wrote a comment.

Google user: nick.bolton.uk


#5

20 Jul 2009: Issue Importer wrote a comment.

Google user: blaze.k...@gmail.com

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.


#6

13 Aug 2009: Issue Importer wrote a comment.

Google user: morgan.ramsay

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.)


#7

6 Oct 2009: Issue Importer wrote a comment.

Google user: aaronjlwebb

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).


#8

13 Oct 2009: Issue Importer wrote a comment.

Google user: john.steiner3

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


#9

26 Oct 2009: Issue Importer wrote a comment.

Google user: stoll...@msu.edu

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


#10

28 Oct 2009: Issue Importer wrote a comment.

Google user: jasonirwin73

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


#11

24 Nov 2009: Issue Importer wrote a comment.

Google user: kyle.mcnally01

Also having the same problem with two windows xp, 1.3.4


#12

4 Jan 2010: Issue Importer wrote a comment.

Google user: chris.j.teague

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).


#13

5 Jan 2010: Issue Importer wrote a comment.

Google user: jasonirwin73

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


#14

20 Jan 2010: Issue Importer wrote a comment.

Google user: Kosi2801

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.


#15

8 Mar 2010: Issue Importer wrote a comment.

Google user: anomdebus

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.


5 Jun 2010: Issue Importer changed Target.

? ?


#16

5 Jun 2010: Issue Importer wrote a comment.

Google user: nick.bolton.uk


#17

25 Jun 2010: Issue Importer wrote a comment.

Google user: lfeistel

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.


#18

18 Jul 2010: Issue Importer wrote a comment.

Google user: emailofchris2

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.


#19

19 Jul 2010: Issue Importer wrote a comment.

Google user: emailofchris2

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.


#20

11 Oct 2010 20:23: Alexander Tchekhovskoy wrote a comment.

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.


13 Jan 2011 16:33: Nick Bolton changed Priority.

Normal High


13 Jan 2011 16:35: Nick Bolton changed Target.

?


#21

24 Jan 2011 22:43: Joshua Kwan wrote a comment.

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.


26 Jan 2011 17:42: Nick Bolton changed Target.

1.3.7


26 Jan 2011 17:42: Nick Bolton changed Found in ver.

1.3.6


26 Jan 2011 17:42: Nick Bolton changed Platform.

Windows


26 Jan 2011 17:42: Nick Bolton changed Found in ver.

1.3.6 1.3.3


#22

22 Apr 2011 08:56: bobby k wrote a comment.

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.


12 Jun 2011 13:05: Nick Bolton changed Status.

Accepted InProgress


12 Jun 2011 13:05: Nick Bolton changed Assignee.

3


#23

12 Jun 2011 13:05: Nick Bolton wrote a comment.

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


12 Jun 2011 13:06: Nick Bolton changed Status.

InProgress Accepted


12 Jun 2011 13:06: Nick Bolton changed Target.

1.3.7 1.3.8


#24

12 Jun 2011 13:06: Nick Bolton wrote a comment.

Ah, dammit, that was an osx fix.


21 Jun 2011 11:33: Nick Bolton changed Assignee.

3


21 Jun 2011 11:41: Nick Bolton changed Target.

1.3.8 ?


#25

1 Jul 2011 13:19: Michael Biber wrote a comment.

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.


1 Feb 2012 11:16: Nick Bolton changed Target.

? 1.4.6


1 Feb 2012 14:44: Nick Bolton changed Target.

1.4.6 1.4.8


10 Mar 2012 19:05: Nick Bolton changed Priority.

High Normal


20 Mar 2012 03:59: Nick Bolton changed Target.

1.4.8 1.4.9


12 Jun 2012 03:47: Nick Bolton changed Target.

1.4.9 1.4.10


#26

25 Jun 2012 18:52: Jason Simone wrote a comment.

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.


#27

19 Jul 2012 18:08: Nick Bolton wrote a comment.

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


#28

19 Jul 2012 18:21: Nick Bolton wrote a comment.

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


25 Jul 2012 01:16: Nick Bolton changed Target.

1.4.10 1.4.11


#29

26 Aug 2012 23:30: Danny King wrote a comment.

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.


#30

7 Sep 2012 11:08: Patrick Huber wrote a comment.

Same as Danny King says. Please fix this!


#31

10 Sep 2012 00:22: Micah Stevens wrote a comment.

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


#32

20 Sep 2012 19:23: Karl Timmermann wrote a comment.

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


#33

4 Oct 2012 19:24: Fai Yip wrote a comment.

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.


#34

4 Oct 2012 19:27: Fai Yip wrote a comment.

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.


#35

10 Oct 2012 13:42: Steve Angelini wrote a comment.

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.


#36

5 Nov 2012 20:05: John Stotler wrote a comment.

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.


#37

23 Dec 2012 11:09: Josh Straub wrote a comment.

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?


#38

28 Jan 2013 19:37: jane blacker wrote a comment.

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?


#39

18 Feb 2013 23:48: Peter Dolkens wrote a comment.

@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 :(


#40

22 Mar 2013 18:20: Mina Hew wrote a comment.

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.


#41

5 Apr 2013 16:33: Jody Shumaker wrote a comment.

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.


#42

21 Jun 2013 11:33: James Valero wrote a comment.

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


#43

8 Aug 2013 23:04: Francisco Saldana wrote a comment.

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.


#44

8 Aug 2013 23:15: Francisco Saldana wrote a comment.

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


#45

13 Aug 2013 14:03: Jody Shumaker wrote a comment.

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?


#46

13 Aug 2013 16:06: Jody Shumaker wrote a comment.

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);

#47

14 Aug 2013 03:20: Jody Shumaker wrote a comment.

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.


#48

9 Oct 2013 15:04: Rafał Wołoszyn wrote a comment.

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


#49

5 Nov 2013 15:10: Geoffrey Pursell wrote a comment.

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.


#50

31 Jan 2014 20:33: Joachim Tingvold wrote a comment.

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...


#51

31 Jan 2014 20:37: Joachim Tingvold wrote a comment.

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 (-:


#52

11 Feb 2014 20:52: Sean Barbour wrote a comment.

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.