> -----Original Message----- > From: Branko Čibej [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 20, 2008 1:57 PM > To: Corey Olsen > Cc: [email protected] > 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.
