apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Corey Olsen" <co...@bungeelabs.com>
Subject RE: apr_file_copy change
Date Wed, 20 Feb 2008 21:24:57 GMT

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

View raw message