/dev/clipboard corrupted

/dev/clipboard corrupted

[Thomas Wolff]

If the clipboard contains large data, the contents retrieved from 
/dev/clipboard gets corrupted.
I compared the following in a few cases:
* cat /dev/clipboard or cp /dev/clipboard (which are equal)
* mouse-paste into mintty, read with cat
* read /dev/clipboard within application

and I found all three results to be different, the correct one sometimes 
being cat /dev/clipboard but not always.
In today's case, the differences occured at byte 10240 and 65536 
respectively, thus 10K-1 bytes or 64K-1 bytes being equal.
------
Thomas

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

Re: /dev/clipboard corrupted

[Andy Koppe]

On 27 June 2012 23:16, Thomas Wolff wrote:
> If the clipboard contains large data, the contents retrieved from
> /dev/clipboard gets corrupted.
> I compared the following in a few cases:
> * cat /dev/clipboard or cp /dev/clipboard (which are equal)
> * mouse-paste into mintty, read with cat
> * read /dev/clipboard within application
>
> and I found all three results to be different, the correct one sometimes
> being cat /dev/clipboard but not always.
> In today's case, the differences occured at byte 10240 and 65536
> respectively, thus 10K-1 bytes or 64K-1 bytes being equal.

I don't know anything about that problem, but note that mintty
accesses the clipboard directly via the Windows API, and that it
converts both Windows line endings ("\r\n") and Unix line endings
("\n") to carriage returns ("\r"), because that's what the Enter key
sends.

Andy

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

Re: /dev/clipboard corrupted

[Corinna Vinschen]

On Jun 28 00:16, Thomas Wolff wrote:
> If the clipboard contains large data, the contents retrieved from
> /dev/clipboard gets corrupted.
> I compared the following in a few cases:
> * cat /dev/clipboard or cp /dev/clipboard (which are equal)
> * mouse-paste into mintty, read with cat
> * read /dev/clipboard within application
> 
> and I found all three results to be different, the correct one
> sometimes being cat /dev/clipboard but not always.
> In today's case, the differences occured at byte 10240 and 65536
> respectively, thus 10K-1 bytes or 64K-1 bytes being equal.

I can't reprocude this.  There's also nothing in the /dev/clipboard
code which would rely on a 10K buffer or so.  64K, yes.  But still,
I tried with wordpad, vi, mintty, cat, and cp with a text file of
about 90K.  No problems.  Do you have any reproducible testcase?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: /dev/clipboard corrupted

[Thomas Wolff]

Am 28.06.2012 10:20, schrieb Corinna Vinschen:
> On Jun 28 00:16, Thomas Wolff wrote:
>> If the clipboard contains large data, the contents retrieved from
>> /dev/clipboard gets corrupted.
>> I compared the following in a few cases:
>> * cat /dev/clipboard or cp /dev/clipboard (which are equal)
>> * mouse-paste into mintty, read with cat
>> * read /dev/clipboard within application
>>
>> and I found all three results to be different, the correct one
>> sometimes being cat /dev/clipboard but not always.
>> In today's case, the differences occured at byte 10240 and 65536
>> respectively, thus 10K-1 bytes or 64K-1 bytes being equal.
> I can't reprocude this.  There's also nothing in the /dev/clipboard
> code which would rely on a 10K buffer or so.  64K, yes.  But still,
> I tried with wordpad, vi, mintty, cat, and cp with a text file of
> about 90K.  No problems.  Do you have any reproducible testcase?
Not really reproducible (maybe later) but some more observations.
I made a small test program to read /dev/clipboard directly with 
different buffer sizes.
I verified that this happens at borders of read() invocations.
It is more likely to happen if there are non-ASCII characters just at 
this border, however, in one case it occurred after 2 blocks read where 
the non-ASCII was between blocks 1 and 2. Also, in one case, a CRLF 
newline at a border was just skipped (with non-ASCII somewhere before, 
probably). Typically, I see 2 bytes skipped, sometimes 1 but sometimes 
also ~100. Quite weird.
I looked at the fhandler_clipboard read() code and somehow suspect the 
wcstomb although the observations are not strictly conclusive.
(It's the non-cygwin-specific branch, after filling the clipboard from 
Windows, e.g. Firefox.)
------
Thomas

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

Re: /dev/clipboard corrupted

[Corinna Vinschen]

On Jun 28 20:33, Thomas Wolff wrote:
> Am 28.06.2012 10:20, schrieb Corinna Vinschen:
> >On Jun 28 00:16, Thomas Wolff wrote:
> >>If the clipboard contains large data, the contents retrieved from
> >>/dev/clipboard gets corrupted.
> >>I compared the following in a few cases:
> >>* cat /dev/clipboard or cp /dev/clipboard (which are equal)
> >>* mouse-paste into mintty, read with cat
> >>* read /dev/clipboard within application
> >>
> >>and I found all three results to be different, the correct one
> >>sometimes being cat /dev/clipboard but not always.
> >>In today's case, the differences occured at byte 10240 and 65536
> >>respectively, thus 10K-1 bytes or 64K-1 bytes being equal.
> >I can't reprocude this.  There's also nothing in the /dev/clipboard
> >code which would rely on a 10K buffer or so.  64K, yes.  But still,
> >I tried with wordpad, vi, mintty, cat, and cp with a text file of
> >about 90K.  No problems.  Do you have any reproducible testcase?
> Not really reproducible (maybe later) but some more observations.
> I made a small test program to read /dev/clipboard directly with
> different buffer sizes.

You know, we just love STCs.  Send you small test program here, plus a
short instruction how you created the clipboard content and how to call
the testcase to see the problem.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: /dev/clipboard corrupted

[Corinna Vinschen]

On Jun 29 11:47, Thomas Wolff wrote:
> On 29.06.2012 11:24, Corinna Vinschen wrote:
> >You know, we just love STCs.  Send you small test program here, plus a
> >short instruction how you created the clipboard content and how to call
> >the testcase to see the problem.
> Sure, so here it is. Open clipboard.txt with notepad, ^A^C to copy
> all, then run the program to see bytes skipped.
> Actually it seems to skip as many bytes per read() as there were
> additional UTF-8 bytes (more bytes than characters) in the preceding
> read block.
> Checking the code again, variable pos seems to be used both as an
> index into the clipboard (WCHAR) and an offset to the resulting
> string length (char) which would explain the effect (not having
> checked all the details though as I'm not familiar with the used
> APIs).

Thanks for the testcase.  I applied a patch which is supposed to fix the
problem.  It should be in the next developer snapshot.  Please give it a
try.


Thanks,
Corinna

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

Re: /dev/clipboard corrupted

[Thomas Wolff]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

On 29.06.2012 11:24, Corinna Vinschen wrote:
> On Jun 28 20:33, Thomas Wolff wrote:
>> Am 28.06.2012 10:20, schrieb Corinna Vinschen:
>>> On Jun 28 00:16, Thomas Wolff wrote:
>>>> If the clipboard contains large data, the contents retrieved from
>>>> /dev/clipboard gets corrupted.
>>>> I compared the following in a few cases:
>>>> * cat /dev/clipboard or cp /dev/clipboard (which are equal)
>>>> * mouse-paste into mintty, read with cat
>>>> * read /dev/clipboard within application
>>>>
>>>> and I found all three results to be different, the correct one
>>>> sometimes being cat /dev/clipboard but not always.
>>>> In today's case, the differences occured at byte 10240 and 65536
>>>> respectively, thus 10K-1 bytes or 64K-1 bytes being equal.
>>> I can't reprocude this.  There's also nothing in the /dev/clipboard
>>> code which would rely on a 10K buffer or so.  64K, yes.  But still,
>>> I tried with wordpad, vi, mintty, cat, and cp with a text file of
>>> about 90K.  No problems.  Do you have any reproducible testcase?
>> Not really reproducible (maybe later) but some more observations.
>> I made a small test program to read /dev/clipboard directly with
>> different buffer sizes.
> You know, we just love STCs.  Send you small test program here, plus a
> short instruction how you created the clipboard content and how to call
> the testcase to see the problem.
Sure, so here it is. Open clipboard.txt with notepad, ^A^C to copy all, 
then run the program to see bytes skipped.
Actually it seems to skip as many bytes per read() as there were 
additional UTF-8 bytes (more bytes than characters) in the preceding 
read block.
Checking the code again, variable pos seems to be used both as an index 
into the clipboard (WCHAR) and an offset to the resulting string length 
(char) which would explain the effect (not having checked all the 
details though as I'm not familiar with the used APIs).
------
Thomas

[-- Attachment #2: clipboard.txt --]
[-- Type: text/plain, Size: 358 bytes --]

Scoloplos ist euryök. Er ist in der gesamten borealen Region in fast 
allen marinen Sedimenten zu finden, die einen sandigen Anteil aufweisen.
Man findet ihn von Grönland bis zum Mittelmeer, in der Nordsee, an der 
kanadischen Küste und im Weißen Meer (Markelova 1981).
Er besiedelt sowohl das «Eulitoral» als auch das „Bathyal“.

[-- Attachment #3: rcb.c --]
[-- Type: text/plain, Size: 687 bytes --]

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char * * argv)
{
	char * fn = "/dev/clipboard";
	int fd = open (fn, O_RDONLY | O_BINARY, 0);
	if (fd < 0) {
		exit (fd);
	}

	int out_tty = isatty (1);

	int filebuflen = 100;
	argc --;
	if (argc > 0) {
		int ret = sscanf (argv [1], "%d", & filebuflen);
	}
	fprintf (stderr, "filebuflen %d\n", filebuflen);
	char * filebuf = malloc (filebuflen + 1);

	int n;
	do {
		n = read (fd, filebuf, filebuflen);
		if (out_tty) {
			filebuf [n] = 0;
			printf ("read %d bytes: <%s>\n", n, filebuf);
		} else {
			fprintf (stderr, "read %d bytes\n", n);
			write (1, filebuf, n);
		}
	} while (n > 0);

	close (fd);
}


[-- Attachment #4: Type: text/plain, Size: 218 bytes --]

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