Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Subject: RE: apr_file_copy change
Date: Wed, 20 Feb 2008 14:24:57 -0700
Message-ID: <5B51CE2F6FBF72409C57E702F06CE4BD117B20@utex01.bungee.com>
In-Reply-To: <47BC9426.3080806@xbc.nu>
Thread-Topic: apr_file_copy change
Thread-Index: Ach0AzJbHHPaFV6XRGW8/tYQlA5xwwAAuwqw
References: <5B51CE2F6FBF72409C57E702F06CE4BD117B1D@utex01.bungee.com>
 <47BC9426.3080806@xbc.nu>
From: "Corey Olsen" <corey@bungeelabs.com>
To: "Branko Cibej" <brane@xbc.nu>
Cc: <dev@apr.apache.org>


> -----Original Message-----
> From: Branko =C8ibej [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
>=20
> 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.
> >
>=20
> 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.
>=20
> 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.
>=20

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.