apr_file_copy change

[Corey Olsen <co...@bungeelabs.com>]

I ran into a problem earlier today calling apr_file_copy where the
from_path and the to_path parameters are the same.  The issue is that in
apr_file_transfer_contents the from file is opened with the APR_READ
flag and then the to file (being the same) opens the file with APR_WRITE
| APR_CREATE | APR_TRUNCATE flags set.  This causes the file to be
truncated to 0 bytes and the transfer ends pretty quickly.

Is this a bug or is this expected behavior with the file_io subsystem?
I'm new to the apr source code so I'm attaching a diff of a change that
fixes the issue for me.  Please let me know if it is good or bad or
otherwise.

Thanks,
Corey Olsen

Index: file_io/unix/copy.c
===================================================================
--- file_io/unix/copy.c (revision 629544)
+++ file_io/unix/copy.c (working copy)
@@ -28,6 +28,11 @@
     apr_finfo_t finfo;
     apr_fileperms_t perms;

+    if (apr_strnatcmp(from_path, to_path) == 0) {
+      status = APR_SUCCESS;
+      return status;
+    }
+
     /* Open source file. */
     status = apr_file_open(&s, from_path, APR_READ, APR_OS_DEFAULT,
pool);
     if (status)

apr_sockaddr_vars_set crash

[Stephen Ince <si...@opendemand.com>]

I seem to be crashing intermittently in apr_sockaddr_vars_set. This method 
looks pretty harmless. The only thing I can think of if alloc_socket in 
apr_socket_create() failed. Does anyone have any insight as to why this may 
happen?

apr: 1.2.12
os: windows XP.


stacktrace.
apr_sockaddr_vars_set(apr_sockaddr_t * 0x00000002, int 2, unsigned short 0) 
line 126 + 6 bytes

set_socket_vars(apr_socket_t * 0x06725f30, int 2, int 1, int 6) line 53

apr_socket_create(apr_socket_t * * 0x02124d70, int 2, int 1, int 6, 
apr_pool_t * 0x03703268) line 148



Steve

RE: apr_file_copy change

[Corey Olsen <co...@bungeelabs.com>]

> -----Original Message-----
> From: Branko Čibej [mailto:brane@xbc.nu]
> Sent: Wednesday, February 20, 2008 1:57 PM
> To: Corey Olsen
> Cc: dev@apr.apache.org
> Subject: Re: apr_file_copy change
> 
> Corey Olsen wrote:
> > I ran into a problem earlier today calling apr_file_copy where the
> > from_path and the to_path parameters are the same.  The issue is that in
> > apr_file_transfer_contents the from file is opened with the APR_READ
> > flag and then the to file (being the same) opens the file with APR_WRITE
> > | APR_CREATE | APR_TRUNCATE flags set.  This causes the file to be
> > truncated to 0 bytes and the transfer ends pretty quickly.
> >
> > Is this a bug or is this expected behavior with the file_io subsystem?
> > I'm new to the apr source code so I'm attaching a diff of a change that
> > fixes the issue for me.  Please let me know if it is good or bad or
> > otherwise.
> >
> 
> Whether it's a bug is a matter of opinion. Unix shell "cp" checks for
> file identity, but one could argue that this is an application-level
> feature.
> 
> But your patch certainly isn't a solution. You can't disprove file
> identity by comparing file paths, that doesn't take links and loopback
> mountpoints and case-insensitive filesystems and such into account.
> 

OK, I can see the point here.  Earlier I was trying to figure out if there was a way to stat the files and then see if the files were the same from the stat.  Obviously my patch was not the best solution but is there a way to check all the conditions required to pass mustard or is that why the "feature / bug" was left out?  If there is I'd write the code for it.

I can see both sides of the application vs system argument as well.  I just wonder if returning APR_SUCCESS and truncating my file is "correct" behavior.

Re: apr_file_copy change

[Branko Čibej <br...@xbc.nu>]

Corey Olsen wrote:
> I ran into a problem earlier today calling apr_file_copy where the
> from_path and the to_path parameters are the same.  The issue is that in
> apr_file_transfer_contents the from file is opened with the APR_READ
> flag and then the to file (being the same) opens the file with APR_WRITE
> | APR_CREATE | APR_TRUNCATE flags set.  This causes the file to be
> truncated to 0 bytes and the transfer ends pretty quickly.
>
> Is this a bug or is this expected behavior with the file_io subsystem?
> I'm new to the apr source code so I'm attaching a diff of a change that
> fixes the issue for me.  Please let me know if it is good or bad or
> otherwise.
>   

Whether it's a bug is a matter of opinion. Unix shell "cp" checks for 
file identity, but one could argue that this is an application-level 
feature.

But your patch certainly isn't a solution. You can't disprove file 
identity by comparing file paths, that doesn't take links and loopback 
mountpoints and case-insensitive filesystems and such into account.

> Thanks,
> Corey Olsen
>
> Index: file_io/unix/copy.c
> ===================================================================
> --- file_io/unix/copy.c (revision 629544)
> +++ file_io/unix/copy.c (working copy)
> @@ -28,6 +28,11 @@
>      apr_finfo_t finfo;
>      apr_fileperms_t perms;
>
> +    if (apr_strnatcmp(from_path, to_path) == 0) {
> +      status = APR_SUCCESS;
> +      return status;
> +    }
> +
>      /* Open source file. */
>      status = apr_file_open(&s, from_path, APR_READ, APR_OS_DEFAULT,
> pool);
>      if (status)
>