Re: General clipboard issue on cygwin (mintty, putclip, getclip, /dev/clipboard)

Hi Takashi,

On 2/23/2026 5:36 PM, Takashi Yano via Cygwin wrote:
> Hi,
> 
> I encountered a clipboard issue common to cygwin.
> 
> Affected components:
> /dev/clipboard, putclip/getclip, mintty
> 
> The issue:
> If the clipbard is opened by `OpenClipboard(NULL)`, occasionally
> SetClipboardData() and GetClipboardData() fails with
> ERROR_CLIPBOARD_NOT_OPEN.
> 
> When UltraVNC Viewer (https://uvnc.com/) is opened, this issue
> happens with a very high probability (> ~90%).
> 
> $ echo AAAA > /dev/clipboard
> echo: write error: Permission denied
> 
> On mintty, text selection by mouse and clicking center button
> fails at the first attempt.
> 
> For putlclip/getclip, the following command outputs nothing
> in a few attempts. ("ABCD" is lost.)
> $ echo ABCD |putclip; for a in `seq 100`; do getclip |putclip; done; getclip
> 
> $
> 
> 
> Solutions:
> This can be solved by passing non-zero HWND to OpenClipboard().
> Therefore, as for mintty, the following patch is ok I think.
> diff --git a/src/winclip.c b/src/winclip.c
> index 12c54525..a7cbe365 100644
> --- a/src/winclip.c
> +++ b/src/winclip.c
> @@ -1324,7 +1324,7 @@ static void
>   do_win_paste(bool do_path)
>   {
>     //printf("OpenClipboard win_paste\n");
> -  if (!OpenClipboard(null))
> +  if (!OpenClipboard(wnd))
>       return;
> 
>     if (cfg.input_clears_selection)
> 
> However, for /dev/clipbard and {put|get}clip, there is no
> suitable HWND to pass to OpenClipboard(). Fortunately, I
> found the patch attached solves the /dev/clipboard issue.
> 
> This is not smart, however it works.
> 
> I think similar patch is ok for putclip/getclip.
> 
> Any suggestions and comments will be appreciated.

I did not try your mintty or UltraVNC tests but the others worked fine 
for me, even when in a loop of 10,000 attempts.

IIUC you are finding OpenClipboard() returning as if it's opened the 
clipboard, but a subsequent operation claims the clipboard is not open.
I'm curious if GetLastError() reports anything from this phantom open.

As for the "not smart" patch :-) I'm leery of cpu-bound loops that might 
not end for some unforeseen situation.  I'd rather you make use of the 
existing max_retry mechanism.  Maybe with shorter Sleep()s, say 100ms, 
and possibly larger retry count.
HTH,

..mark

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple