#152 Clipboard sometimes unusable through RDesktop

closed
nobody
None
5
2005-11-12
2005-05-10
No

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

Discussion

  • getmoresoon

    getmoresoon - 2005-06-14

    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)

     
  • Andrew Fedorov

    Andrew Fedorov - 2005-08-08

    Logged In: YES
    user_id=725635

    This things patched in Win 2003 SP1.

     
  • Nobody/Anonymous

    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

     
  • Nobody/Anonymous

    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?

     
  • Ilya Konstantinov

    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?

     
  • Ilya Konstantinov

    • status: open --> pending
     
  • SourceForge Robot

    • status: pending --> closed
     
  • SourceForge Robot

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

     
  • SLaViR

    SLaViR - 2007-09-12

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

     
  • SLaViR

    SLaViR - 2007-09-12

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

     
  • Gilboa Davara

    Gilboa Davara - 2008-07-02

    Logged In: YES
    user_id=721273
    Originator: NO

    FYI - Problem can be reproduced in rdesktop 1.6 (F8/x86_64) / Windows XP SP2.