On Dec 18, 2007 12:05 PM, Erik Huelsmann <ehuels@gmail.com> wrote:
>
> On 12/18/07, Norbert Unterberg <nunterberg@gmail.com> wrote:
> > You are on the wrong track here.The problem is not what BUFSIZ is
> > defined on the different platforms but how APR uses it.
> > BUFSIZ is the size of the buffer that can be set for buffered streams
> > with the setbuf() call. Nothing more. MSDN just says: "BUFSIZ is the
> > required user-allocated buffer for the setvbuf routine." BUFSIZ is NOT
> > a suggestion for a buffer size when dealing with large binary files.
> > So the bug is in APR where BUFSIZ is used for something it was not designed for.
> >
> > This has already been discussed for years on this list, but nothing has changed:
> > http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=82087
> > http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=113549
> >
> > So it is clearly an apr and not a windows issue.
>
> Providing a patch might help:
Thank you for the invitation, but no thank you. Diagnosing if someone
is ill and actually performing the operation are two different things,
and I currently do not want to jump over the high hurdles of actually
creating a politically and stylistically correct patch to an APR
library function!
> They define a buffer size of their own
> (APR_FILE_BUFSIZE, defined to 4096 on Win32) which should probably be
> used for binary file copies since it's used for buffered files as
> well.
As already suggested three years ago, why not call the native
CopyFile() function on Windows which will likely have best possible
performance without filling with different buffer sizes?
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 18 13:27:18 2007