* /dev/clipboard corrupted @ 2012-06-27 22:16 Thomas Wolff 2012-06-28 8:04 ` Andy Koppe 2012-06-28 8:21 ` Corinna Vinschen 0 siblings, 2 replies; 7+ messages in thread From: Thomas Wolff @ 2012-06-27 22:16 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: /dev/clipboard corrupted 2012-06-27 22:16 /dev/clipboard corrupted Thomas Wolff @ 2012-06-28 8:04 ` Andy Koppe 2012-06-28 8:21 ` Corinna Vinschen 1 sibling, 0 replies; 7+ messages in thread From: Andy Koppe @ 2012-06-28 8:04 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: /dev/clipboard corrupted 2012-06-27 22:16 /dev/clipboard corrupted Thomas Wolff 2012-06-28 8:04 ` Andy Koppe @ 2012-06-28 8:21 ` Corinna Vinschen 2012-06-28 18:33 ` Thomas Wolff 1 sibling, 1 reply; 7+ messages in thread From: Corinna Vinschen @ 2012-06-28 8:21 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: /dev/clipboard corrupted 2012-06-28 8:21 ` Corinna Vinschen @ 2012-06-28 18:33 ` Thomas Wolff 2012-06-29 7:24 ` Corinna Vinschen 0 siblings, 1 reply; 7+ messages in thread From: Thomas Wolff @ 2012-06-28 18:33 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: /dev/clipboard corrupted 2012-06-28 18:33 ` Thomas Wolff @ 2012-06-29 7:24 ` Corinna Vinschen 0 siblings, 0 replies; 7+ messages in thread From: Corinna Vinschen @ 2012-06-29 7:24 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <1286377403.634959.1340961856516.JavaMail.open-xchange@email.1und1.de>]
* Re: /dev/clipboard corrupted [not found] <1286377403.634959.1340961856516.JavaMail.open-xchange@email.1und1.de> @ 2012-06-29 9:47 ` Thomas Wolff 2012-07-02 20:40 ` Corinna Vinschen 0 siblings, 1 reply; 7+ messages in thread From: Thomas Wolff @ 2012-06-29 9:47 UTC (permalink / raw) To: cygwin [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: /dev/clipboard corrupted 2012-06-29 9:47 ` Thomas Wolff @ 2012-07-02 20:40 ` Corinna Vinschen 0 siblings, 0 replies; 7+ messages in thread From: Corinna Vinschen @ 2012-07-02 20:40 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-07-02 20:40 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-27 22:16 /dev/clipboard corrupted Thomas Wolff 2012-06-28 8:04 ` Andy Koppe 2012-06-28 8:21 ` Corinna Vinschen 2012-06-28 18:33 ` Thomas Wolff 2012-06-29 7:24 ` Corinna Vinschen [not found] <1286377403.634959.1340961856516.JavaMail.open-xchange@email.1und1.de> 2012-06-29 9:47 ` Thomas Wolff 2012-07-02 20:40 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).