From: SourceForge.net <no...@so...> - 2007-09-12 12:03:43
|
Bugs item #1198945, was opened at 2005-05-10 15:06 Message generated for change (Comment added) made by slavir You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381347&aid=1198945&group_id=24366 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Jernej Simončič (jernejs) Assigned to: Nobody/Anonymous (nobody) Summary: Clipboard sometimes unusable through RDesktop Initial Comment: Pretty often when I work with RDesktop, I'm unable to copy & paste inside the session. With most applications this just silently fails, but a few report errors such as "Clipboard locked" or "Cannot open clipboard". I haven't encountered this when working with RDP from Windows. This happens both in 1.4.0 and 1.4.1 (I haven't tried with older versions). ---------------------------------------------------------------------- Comment By: SLaViR (slavir) Date: 2007-09-12 16:03 Message: Logged In: YES user_id=1888772 Originator: NO i am tested last cvs version 1.5.0. (unstable but worked - just replace BOOL - on RD_BOOL, and when ./configure --with-smartcard=no) ... Some time, some abnormal soft, (but this software is very important for our business) - generate zero length packet from Windows side... and soft is blocked(soft or rdpclip.exe - kill to unblock) so... - in cliprdr.c void cliprdr_send_data(uint8 * data, uint32 length) { DEBUG_CLIPBOARD(("cliprdr_send_data\n")); + if (length!=0){ cliprdr_send_packet(CLIPRDR_DATA_RESPONSE, CLIPRDR_RESPONSE, data, length); + } + else{ + DEBUG_CLIPBOARD(("TRY zero length cliprdr_send_data\n")); + } } and static void cliprdr_process(STREAM s) { uint16 type, status; uint32 length, format; uint8 *data; in_uint16_le(s, type); in_uint16_le(s, status); in_uint32_le(s, length); data = s->p; DEBUG_CLIPBOARD(("CLIPRDR recv: type=%d, status=%d, length=%d\n", type, status, length)); // + if ((length==0)&&(type!=CLIPRDR_CONNECT)){ + DEBUG_CLIPBOARD(("TRY CLIPRDR recv: 0 length data\n")); + return; + } after patch - still work... ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2005-11-12 06:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2005-10-28 14:26 Message: Logged In: YES user_id=335423 The clipboard process works like this: - You do a Paste operation in a Windows program. - The Windows program requests clipboard data from RDPCLIP and waits. - RDPCLIP requests clipboard data from the RDP client. - RDP client (us) request clipboard data from the X client (e.g. xterm, Mozilla -- whoever!) that offers it. - X client sends up back the clipboard data. - We pass it on to RDP, the Windows program receives it and unblocks from its wait. If we never receive the info from the X client, the Windows program will never unblock. For that cause, we might decide on a timeout in rdesktop, after which we'll send an empty clipboard response. Can you confirm my suspicion? Can you compile with --enable-debug-clipboard, perform the hanging operation and attach the output here? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-10-01 03:08 Message: Logged In: NO Having the exact same problem on Windows XP SP2, tried to find a fix for it, but no avail. Does anybody know what to do? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-09-22 00:06 Message: Logged In: NO Check into the RDPCLIP.EXE version on your 2000 or 2003 server. The version from 2003 sp1 fixes the problem. Check Microsoft for the RDPCLIP.exe hotfix. -JD ---------------------------------------------------------------------- Comment By: Andrew Fedorov (warlib) Date: 2005-08-08 16:23 Message: Logged In: YES user_id=725635 This things patched in Win 2003 SP1. ---------------------------------------------------------------------- Comment By: getmoresoon (getmoresoon) Date: 2005-06-14 21:55 Message: Logged In: YES user_id=1296697 I occasionally encounter a similar problem. Often, pasting into the Win XP session will result in locking the recipient application. Bringing up the taskmanager and killing the RDPClip.exe process will get your app back, but you will lose any ability to cut/paste from your Linux desktop into WinXP until the Xp machine is rebooted. (or you restart the process, which you can do from the XP command line) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381347&aid=1198945&group_id=24366 |
From: SourceForge.net <no...@so...> - 2007-09-12 12:04:07
|
Bugs item #1198945, was opened at 2005-05-10 15:06 Message generated for change (Comment added) made by slavir You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381347&aid=1198945&group_id=24366 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Jernej Simončič (jernejs) Assigned to: Nobody/Anonymous (nobody) Summary: Clipboard sometimes unusable through RDesktop Initial Comment: Pretty often when I work with RDesktop, I'm unable to copy & paste inside the session. With most applications this just silently fails, but a few report errors such as "Clipboard locked" or "Cannot open clipboard". I haven't encountered this when working with RDP from Windows. This happens both in 1.4.0 and 1.4.1 (I haven't tried with older versions). ---------------------------------------------------------------------- Comment By: SLaViR (slavir) Date: 2007-09-12 16:04 Message: Logged In: YES user_id=1888772 Originator: NO i am tested last cvs version 1.5.0. (unstable but worked - just replace BOOL - on RD_BOOL, and when ./configure --with-smartcard=no) ... Some time, some abnormal soft, (but this software is very important for our business) - generate zero length packet from Windows side... and soft is blocked(soft or rdpclip.exe - kill to unblock) so... - in cliprdr.c void cliprdr_send_data(uint8 * data, uint32 length) { DEBUG_CLIPBOARD(("cliprdr_send_data\n")); + if (length!=0){ cliprdr_send_packet(CLIPRDR_DATA_RESPONSE, CLIPRDR_RESPONSE, data, length); + } + else{ + DEBUG_CLIPBOARD(("TRY zero length cliprdr_send_data\n")); + } } and static void cliprdr_process(STREAM s) { uint16 type, status; uint32 length, format; uint8 *data; in_uint16_le(s, type); in_uint16_le(s, status); in_uint32_le(s, length); data = s->p; DEBUG_CLIPBOARD(("CLIPRDR recv: type=%d, status=%d, length=%d\n", type, status, length)); // + if ((length==0)&&(type!=CLIPRDR_CONNECT)){ + DEBUG_CLIPBOARD(("TRY CLIPRDR recv: 0 length data\n")); + return; + } after patch - still work... ---------------------------------------------------------------------- Comment By: SLaViR (slavir) Date: 2007-09-12 16:03 Message: Logged In: YES user_id=1888772 Originator: NO i am tested last cvs version 1.5.0. (unstable but worked - just replace BOOL - on RD_BOOL, and when ./configure --with-smartcard=no) ... Some time, some abnormal soft, (but this software is very important for our business) - generate zero length packet from Windows side... and soft is blocked(soft or rdpclip.exe - kill to unblock) so... - in cliprdr.c void cliprdr_send_data(uint8 * data, uint32 length) { DEBUG_CLIPBOARD(("cliprdr_send_data\n")); + if (length!=0){ cliprdr_send_packet(CLIPRDR_DATA_RESPONSE, CLIPRDR_RESPONSE, data, length); + } + else{ + DEBUG_CLIPBOARD(("TRY zero length cliprdr_send_data\n")); + } } and static void cliprdr_process(STREAM s) { uint16 type, status; uint32 length, format; uint8 *data; in_uint16_le(s, type); in_uint16_le(s, status); in_uint32_le(s, length); data = s->p; DEBUG_CLIPBOARD(("CLIPRDR recv: type=%d, status=%d, length=%d\n", type, status, length)); // + if ((length==0)&&(type!=CLIPRDR_CONNECT)){ + DEBUG_CLIPBOARD(("TRY CLIPRDR recv: 0 length data\n")); + return; + } after patch - still work... ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2005-11-12 06:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2005-10-28 14:26 Message: Logged In: YES user_id=335423 The clipboard process works like this: - You do a Paste operation in a Windows program. - The Windows program requests clipboard data from RDPCLIP and waits. - RDPCLIP requests clipboard data from the RDP client. - RDP client (us) request clipboard data from the X client (e.g. xterm, Mozilla -- whoever!) that offers it. - X client sends up back the clipboard data. - We pass it on to RDP, the Windows program receives it and unblocks from its wait. If we never receive the info from the X client, the Windows program will never unblock. For that cause, we might decide on a timeout in rdesktop, after which we'll send an empty clipboard response. Can you confirm my suspicion? Can you compile with --enable-debug-clipboard, perform the hanging operation and attach the output here? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-10-01 03:08 Message: Logged In: NO Having the exact same problem on Windows XP SP2, tried to find a fix for it, but no avail. Does anybody know what to do? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-09-22 00:06 Message: Logged In: NO Check into the RDPCLIP.EXE version on your 2000 or 2003 server. The version from 2003 sp1 fixes the problem. Check Microsoft for the RDPCLIP.exe hotfix. -JD ---------------------------------------------------------------------- Comment By: Andrew Fedorov (warlib) Date: 2005-08-08 16:23 Message: Logged In: YES user_id=725635 This things patched in Win 2003 SP1. ---------------------------------------------------------------------- Comment By: getmoresoon (getmoresoon) Date: 2005-06-14 21:55 Message: Logged In: YES user_id=1296697 I occasionally encounter a similar problem. Often, pasting into the Win XP session will result in locking the recipient application. Bringing up the taskmanager and killing the RDPClip.exe process will get your app back, but you will lose any ability to cut/paste from your Linux desktop into WinXP until the Xp machine is rebooted. (or you restart the process, which you can do from the XP command line) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381347&aid=1198945&group_id=24366 |
From: SourceForge.net <no...@so...> - 2008-07-02 11:46:26
|
Bugs item #1198945, was opened at 2005-05-10 14:06 Message generated for change (Comment added) made by gilboa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381347&aid=1198945&group_id=24366 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Jernej Simončič (jernejs) Assigned to: Nobody/Anonymous (nobody) Summary: Clipboard sometimes unusable through RDesktop Initial Comment: Pretty often when I work with RDesktop, I'm unable to copy & paste inside the session. With most applications this just silently fails, but a few report errors such as "Clipboard locked" or "Cannot open clipboard". I haven't encountered this when working with RDP from Windows. This happens both in 1.4.0 and 1.4.1 (I haven't tried with older versions). ---------------------------------------------------------------------- Comment By: Gilboa Davara (gilboa) Date: 2008-07-02 14:45 Message: Logged In: YES user_id=721273 Originator: NO FYI - Problem can be reproduced in rdesktop 1.6 (F8/x86_64) / Windows XP SP2. ---------------------------------------------------------------------- Comment By: SLaViR (slavir) Date: 2007-09-12 15:04 Message: Logged In: YES user_id=1888772 Originator: NO i am tested last cvs version 1.5.0. (unstable but worked - just replace BOOL - on RD_BOOL, and when ./configure --with-smartcard=no) ... Some time, some abnormal soft, (but this software is very important for our business) - generate zero length packet from Windows side... and soft is blocked(soft or rdpclip.exe - kill to unblock) so... - in cliprdr.c void cliprdr_send_data(uint8 * data, uint32 length) { DEBUG_CLIPBOARD(("cliprdr_send_data\n")); + if (length!=0){ cliprdr_send_packet(CLIPRDR_DATA_RESPONSE, CLIPRDR_RESPONSE, data, length); + } + else{ + DEBUG_CLIPBOARD(("TRY zero length cliprdr_send_data\n")); + } } and static void cliprdr_process(STREAM s) { uint16 type, status; uint32 length, format; uint8 *data; in_uint16_le(s, type); in_uint16_le(s, status); in_uint32_le(s, length); data = s->p; DEBUG_CLIPBOARD(("CLIPRDR recv: type=%d, status=%d, length=%d\n", type, status, length)); // + if ((length==0)&&(type!=CLIPRDR_CONNECT)){ + DEBUG_CLIPBOARD(("TRY CLIPRDR recv: 0 length data\n")); + return; + } after patch - still work... ---------------------------------------------------------------------- Comment By: SLaViR (slavir) Date: 2007-09-12 15:03 Message: Logged In: YES user_id=1888772 Originator: NO i am tested last cvs version 1.5.0. (unstable but worked - just replace BOOL - on RD_BOOL, and when ./configure --with-smartcard=no) ... Some time, some abnormal soft, (but this software is very important for our business) - generate zero length packet from Windows side... and soft is blocked(soft or rdpclip.exe - kill to unblock) so... - in cliprdr.c void cliprdr_send_data(uint8 * data, uint32 length) { DEBUG_CLIPBOARD(("cliprdr_send_data\n")); + if (length!=0){ cliprdr_send_packet(CLIPRDR_DATA_RESPONSE, CLIPRDR_RESPONSE, data, length); + } + else{ + DEBUG_CLIPBOARD(("TRY zero length cliprdr_send_data\n")); + } } and static void cliprdr_process(STREAM s) { uint16 type, status; uint32 length, format; uint8 *data; in_uint16_le(s, type); in_uint16_le(s, status); in_uint32_le(s, length); data = s->p; DEBUG_CLIPBOARD(("CLIPRDR recv: type=%d, status=%d, length=%d\n", type, status, length)); // + if ((length==0)&&(type!=CLIPRDR_CONNECT)){ + DEBUG_CLIPBOARD(("TRY CLIPRDR recv: 0 length data\n")); + return; + } after patch - still work... ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2005-11-12 05:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2005-10-28 12:26 Message: Logged In: YES user_id=335423 The clipboard process works like this: - You do a Paste operation in a Windows program. - The Windows program requests clipboard data from RDPCLIP and waits. - RDPCLIP requests clipboard data from the RDP client. - RDP client (us) request clipboard data from the X client (e.g. xterm, Mozilla -- whoever!) that offers it. - X client sends up back the clipboard data. - We pass it on to RDP, the Windows program receives it and unblocks from its wait. If we never receive the info from the X client, the Windows program will never unblock. For that cause, we might decide on a timeout in rdesktop, after which we'll send an empty clipboard response. Can you confirm my suspicion? Can you compile with --enable-debug-clipboard, perform the hanging operation and attach the output here? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-10-01 02:08 Message: Logged In: NO Having the exact same problem on Windows XP SP2, tried to find a fix for it, but no avail. Does anybody know what to do? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-09-21 23:06 Message: Logged In: NO Check into the RDPCLIP.EXE version on your 2000 or 2003 server. The version from 2003 sp1 fixes the problem. Check Microsoft for the RDPCLIP.exe hotfix. -JD ---------------------------------------------------------------------- Comment By: Andrew Fedorov (warlib) Date: 2005-08-08 15:23 Message: Logged In: YES user_id=725635 This things patched in Win 2003 SP1. ---------------------------------------------------------------------- Comment By: getmoresoon (getmoresoon) Date: 2005-06-14 20:55 Message: Logged In: YES user_id=1296697 I occasionally encounter a similar problem. Often, pasting into the Win XP session will result in locking the recipient application. Bringing up the taskmanager and killing the RDPClip.exe process will get your app back, but you will lose any ability to cut/paste from your Linux desktop into WinXP until the Xp machine is rebooted. (or you restart the process, which you can do from the XP command line) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381347&aid=1198945&group_id=24366 |