You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Max Bowsher <ma...@ukf.net> on 2006/03/11 12:43:20 UTC
apr_file_copy/append should be binary?
It seems to me that apr_file_copy() and apr_file_append() should behave
in a raw byte-for-byte manner, always.
Therefore, I propose to specify APR_BINARY in all associated
apr_file_open() calls.
The only platform I *know* that this affects is Cygwin.
Max.
Index: file_io/unix/copy.c
===================================================================
--- file_io/unix/copy.c (revision 385062)
+++ file_io/unix/copy.c (working copy)
@@ -29,7 +29,8 @@
apr_fileperms_t perms;
/* Open source file. */
- status = apr_file_open(&s, from_path, APR_READ, APR_OS_DEFAULT, pool);
+ status = apr_file_open(&s, from_path, APR_READ | APR_BINARY,
+ APR_OS_DEFAULT, pool);
if (status)
return status;
@@ -46,7 +47,7 @@
perms = to_perms;
/* Open dest file. */
- status = apr_file_open(&d, to_path, flags, perms, pool);
+ status = apr_file_open(&d, to_path, flags | APR_BINARY, perms, pool);
if (status) {
apr_file_close(s); /* toss any error */
return status;
Re: apr_file_copy/append should be binary?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 3/11/06, Jeff Trawick <tr...@gmail.com> wrote:
> On 3/11/06, Max Bowsher <ma...@ukf.net> wrote:
> > It seems to me that apr_file_copy() and apr_file_append() should behave
> > in a raw byte-for-byte manner, always.
>
> +1
>
> if the source file is in native text format (or both files for
> append), the right thing will happen... if the source file is not in
> native text format, they can't expect apr_file_copy() to be used in
> lieu of unix2dos-type command
+1
-garrett
Re: apr_file_copy/append should be binary?
Posted by Jeff Trawick <tr...@gmail.com>.
On 3/11/06, Max Bowsher <ma...@ukf.net> wrote:
> It seems to me that apr_file_copy() and apr_file_append() should behave
> in a raw byte-for-byte manner, always.
+1
if the source file is in native text format (or both files for
append), the right thing will happen... if the source file is not in
native text format, they can't expect apr_file_copy() to be used in
lieu of unix2dos-type command
Re: apr_file_copy/append should be binary?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Max Bowsher wrote:
> It seems to me that apr_file_copy() and apr_file_append() should behave
> in a raw byte-for-byte manner, always.
>
> Therefore, I propose to specify APR_BINARY in all associated
> apr_file_open() calls.
>
> The only platform I *know* that this affects is Cygwin.
Irrespective if this is the only one -today-, I agree 100% and would encourage
you to apply the patch on all three living branches (0.9/1.2/trunk).
I don't think there is any room for copy/append to modify data whatsoever.
Bill
> Index: file_io/unix/copy.c
> ===================================================================
> --- file_io/unix/copy.c (revision 385062)
> +++ file_io/unix/copy.c (working copy)
> @@ -29,7 +29,8 @@
> apr_fileperms_t perms;
>
> /* Open source file. */
> - status = apr_file_open(&s, from_path, APR_READ, APR_OS_DEFAULT, pool);
> + status = apr_file_open(&s, from_path, APR_READ | APR_BINARY,
> + APR_OS_DEFAULT, pool);
> if (status)
> return status;
>
> @@ -46,7 +47,7 @@
> perms = to_perms;
>
> /* Open dest file. */
> - status = apr_file_open(&d, to_path, flags, perms, pool);
> + status = apr_file_open(&d, to_path, flags | APR_BINARY, perms, pool);
> if (status) {
> apr_file_close(s); /* toss any error */
> return status;
>