Re: /dev/clipboard sometimes fails to set CF_UNICODETEXT data.

[Andrey Repin <anrdaemon@yandex.ru>]

Greetings, Takashi Yano!

> On Tue, 5 Jul 2022 00:42:50 -0700
> Mark Geisert wrote:
>> Hi Takashi,
>> 
>> Takashi Yano wrote:
>> > Hello,
>> > 
>> > In one of my PCs,
>> > dd if=/dev/urandom count=10 | xxd > /dev/clipboard
>> > sometimes fails to set CF_UNICODETEXT data.
>> > As a result, pasting clipboard to notepad does not work.
>> > 
>> > Even in the case, cygnativeformat data is set correctly.
>> > So, "cat /dev/clipboard" works.
>> > 
>> > This problem depends on machine very much.
>> > 
>> > My one PC with Xeon E3-1281 v3 CPU has a high probability of failure,
>> > however, another machine with Core i7-6700K CPU does not.
>> > 
>> > I looked into this problem, and found OpenClipboard() for
>> > CF_UNICODETEXT fails. It seems that OpenClipboard() just
>> > after CloseClipboard() has high probability of failure.
>> > 
>> > You can see the following test case immediately stops with error.
>> > Even with Core i7-6700K CPU machine above, the test case fails.

> Additional information:
> In the machine with Xeon E3-1281 v3 CPU, the test case fails
> in a several times of the loop, while it fails after 1000 to
> 3000 times of the loop in the machine with Core i7-6700K CPU.

> The probability of failure depends much on machine.

MFG… this might as well explain the issues OpenOffice having with clipboard
content. I'll forward your findings.

>> > #include <windows.h>
>> > #include <stdio.h>
>> > 
>> > int main()
>> > {
>> >     for (;;) {
>> >             if (!OpenClipboard(0)) {
>> >                     printf("Open error.\n");
>> >                     break;
>> >             }
>> >             if (!EmptyClipboard()) {
>> >                     printf("Empty error.\n");
>> >                     break;
>> >             }
>> >             if (!CloseClipboard()) {
>> >                     printf("Cloes error.\n");
>> >                     break;
>> >             }
>> >     }
>> >     return 0;
>> > }
>> > 
>> > I also found the patch attached solves the issue.
>> > 
>> > I would appreciate any suggestion.
>> 
>> Would be neet if this patch wasn't needed, but, oh well.  My only comment on the 
>> patch would be to possibly call the new wrapper function MyOpenClipboard, or 
>> CygOpenClipboard, to help keep the name paired with CloseClipboard.

> Thanks for the comment. IIUC, the camel case name should be
> used only for Win32 APIs related. However, this is the wrapper
> for Win32 API. So, it might be acceptable. In other places,
> some wrapper functions are named as camel case.

> Corinna, WDYT?

>> I suppose it might happen in the future that a faster processor will require the 
>> loop count to be made larger.  Once again, oh well.

> Maybe. In my most cases, OpenClipboard() successes after one
> or two times of retrying. So, I think max_retry = 10 is enough
> for the time being.

>> My 2c (adjusted for inflation),

> -- 
> Takashi Yano <takashi.yano@nifty.ne.jp>



-- 
With best regards,
Andrey Repin
Tuesday, July 5, 2022 17:44:56

Sorry for my terrible english...