This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: upload: diffstat-1.40-1, tar-1.15.1-1


> 
> i.e., as I said, it sounds like you changed the behavior.  If you want
> to fix the incremental files so that they are always created with \n
> endings that would be great.  Otherwise, please don't use the underlying
> mount option *for anything*.

Underlying mount points for reading are harmless if the code doing
the reading strips the \r (which is good coding style for any text
file with arbitrary line endings).  Only if the code is not robust do
you need to force a text mode read as a minimally-intrusive patch.

I will re-audit my tar patches, and if there is anywhere that a file is not
created in binary mode (even when it contains human-readable text),
or where a read is not robust without forcing text mode, fix it
accordingly and release tar-1.15.1-2.  I think we have been in
violent agreement about this issue.  By the way, creat() implies
mount mode unless you link against binmode.o, so part of my
patches in 1.15.1-1 was already turning all creat()s into
open(O_WRONLY|O_TRUNC|O_CREAT|O_BINARY).

> 
> >I agree that the philosophy should not change; file reads should be
> >tolerant, and file writes should prefer \n line endings.
> 
> How can that be the case if you are using the "underlying mount point"?

OK, I concede that file writes cannot prefer \n line endings unless
the file is opened in binary mode, even if the contents of the file
are human-readable such that it can be parsed with \r\n endings.

On an unrelated note, is there anything wrong with uploading
diffstat-1.40-1, which got overlooked by all this text vs. binary
discussion?

--
Eric Blake



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]