> > 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
