From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Cc: キャロウ マーク <github@callow.im>
Subject: Re: Pipes truncating data in cygwin from main and cygwin-3_4-branch
Date: Tue, 15 Aug 2023 09:30:42 +0900 [thread overview]
Message-ID: <20230815093042.4c5fd1034837098aaff45e10@nifty.ne.jp> (raw)
In-Reply-To: <13B0370E-B61A-44B9-A885-5FF1B8F4AC5F@callow.im>
On Mon, 14 Aug 2023 20:51:39 +0900
キャロウ マーク wrote:
> I have a problem that looks like pipes are truncating data when I cat a file to my program’s stdin. A simple `cat foo | cat > bar` works fine. bar ends up identical to foo. It is more complicated than that. My application is doing this
> std::stringstream buffer;
> buffer << std::cin.rdbuf();
> std::istream* isp = &buffer;
> Initial reads after this work fine. Once the app has read everything up to the payload data in the file, it does
>
> off_t dataStart = (off_t)(isp->tellg());
> isp->seekg(0, ios_base::end);
> off_t dataEnd = (off_t)(isp->tellg());
> dataSizeInFile = dataEnd - dataStart;
> The tellg result shows the size is significantly less than the actual file data. 43k less in a 170k file. It is seemingly being truncated somewhere.
>
> Later the app does
>
> isp->seekg(0);
> std::streambuf* _streambuf = (isp->rdbuf());
> and starts reading from _streambuf. All data read from _streambuf is gibberish.
>
> The application code makes no distinction between a pipe and stdin redirection from a file. It just uses std::cin. stdin redirection still works.
>
> I created a minimal reproducer. More on that in a moment.
>
> I first encountered this in Git for Windows 2.41.0. I had no problem in previous versions. I reported this to the Git for Windows project. See https://github.com/git-for-windows/git/issues/4464. You can find the minimal reproducer over there. It consists of 2 parts, a script and a small c++ program. The script finds the size of the target file then cats it to the test program passing the file size as a command line option. The test program does what I have described above and compares the file size determined from the seek to the end with the provided size.
>
> A G4W project member reports that the problem reproduces on vanilla Cygwin in the branches mentioned in the subject and that G4W and MSYS2 are on the cygwin-3_4-branch release train. He recommends reporting the bug to you, You can find his(?) full comment here <https://github.com/git-for-windows/git/issues/4464#issuecomment-1671137446>.
Your test case does not work in command prompt as well.
Try
type testfile | test-pipe sizeoftestfile
in command prompt. It will fail.
New pipe implementation since cygwin 3.4.x provides the pipes
more similar to pipe in command prompt for non-cygwin apps.
Since your test case is compiled with cl.exe, it is non-cygwin
apps.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
next parent reply other threads:[~2023-08-15 0:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <13B0370E-B61A-44B9-A885-5FF1B8F4AC5F@callow.im>
2023-08-15 0:30 ` Takashi Yano [this message]
[not found] ` <CCC360AD-21B1-40E4-8B6B-FCFAF5612939@callow.im>
2023-08-15 6:42 ` Takashi Yano
[not found] ` <FCF9C3F3-7ED6-406A-8420-05379E4C5875@callow.im>
2023-08-15 9:45 ` Takashi Yano
2023-08-15 10:01 ` キャロウ マーク
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230815093042.4c5fd1034837098aaff45e10@nifty.ne.jp \
--to=takashi.yano@nifty.ne.jp \
--cc=cygwin@cygwin.com \
--cc=github@callow.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).