bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/4] Cross compiling sharutils


From: Eli Zaretskii
Subject: Re: [PATCH 0/4] Cross compiling sharutils
Date: Thu, 21 May 2015 19:12:20 +0300

> Date: Wed, 20 May 2015 21:40:16 -0700
> From: Filipe Brandenburger <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, Eric Blake <address@hidden>, 
> address@hidden
> 
> On Wed, May 20, 2015 at 9:05 PM, Filipe Brandenburger
> <address@hidden> wrote:
> > I got my hands on a Windows instance and installed cygwin on it, so
> > I'm currently running cygwin tests to ensure there's no regression.
> 
> Hmmm... So I checked cygwin and I built a version of the unmodified
> tarball and then another one where I just changed the freadonly_binary
> to "r" in the popen call.
> 
> I tried shar -C gzip/xz/bzip2 on many files, unpacked them by running
> the shar script and compared them with the original, but I didn't
> really manage to reproduce the issue by which popen with a simple "r"
> corrupted the files...

It was I who added the binary mode to some popen calls in Sharutils.
I did that when I worked on the MinGW port of Sharutils.  The reason
is simple: you _must_ read output from a compressor in binary mode,
because what the compressor outputs is binary data, not text.  If you
read it in text mode, the read will stop on the first ^Z character,
and it will strip CR characters from the data.  (I'm guessing that the
former doesn't happen in Cygwin, so you don't see problems because
your examples, by sheer luck, didn't have CR characters in the
compressed data, or maybe didn't have them before an LF character.)

> So I'm really at a loss at why this code was even there, as I can't
> really think of another platform that would conceivably handle
> popen("rb") different from popen("r") if cygwin doesn't...

See above: all Windows platforms do.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]