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


On Wed, Aug 17, 2005 at 04:10:36PM +0000, Eric Blake wrote:
>> On Aug 17 10:56, Christopher Faylor wrote:
>> > On Wed, Aug 17, 2005 at 06:24:50AM -0600, Eric Blake wrote:
>> > >tar: new maintainer, new upstream release.  Instead of linking against
>> > >binmode.o and forcing text mode on the exceptions even on binary mounts,
>> > 
>> > I'm not sure what the above is implying but I didn't link with binmode.o
>> > when I packaged tar.
>
>Diffing the contents of /usr/src/tar-1.13.25-7 against a pristine
>tar-1.13.25 tarball shows that you indeed patched configure.ac
>to use binmode.o:
>-test "$ac_cv_func_strstr" = yes || LIBOBJS="$LIBOBJS strstr.o"
>+test "$ac_cv_func_strstr" = yes || AC_LIBOBJ(strstr)
>+
>+if test "$GCC" = "yes"; then
>+    binmode=`$CC -print-file-name=binmode.o < /dev/null`
>+    case "$binmode" in
>+      /*) LDEXTRA="$LDEXTRA $binmode" ;;
>+    esac
>+fi
>+AC_SUBST(LDEXTRA)

Sorry.  I noticed that I commented this out of the mknetrel sources but
didn't remember that I'd changed the configury.

>Then you went through the sources, and for all files that manipulate
>human-readable files (such as file name lists, as opposed to actual
>tars), you added FOPEN_TEXT_READ, defined as "rt", to fopen calls,
>and O_TEXT to open calls.  All file manipulations that were on binary
>files you left alone.  This means that in some cases, your patch to
>1.13.25 actually created text files (\r\n endings) on a binary mount
>point.

I see that I did change an O_RDWR file to use O_TEXT, so, regrettably,
this always created a file with CRLF endings.  It was not my intention
to do so, however.

Other than that, I don't see any place where a file would be created
with CRLF line endings.

>I did the opposite.  Instead of forcing binmode.o then specifying
>exceptions that should be text mode, I fixed all remaining opens
>to specify "rb" or O_BINARY as appropriate, leaving only the
>human-readable files to track the underlying mount point at
>creation,

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

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

cgf


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