> No, I spoke correctly.
>
> Though perhaps unclearly: by "it's a bug either way," I mean if you are
> running an unbounded loop without pool cleanups, you have a bug. If you
> notice this bug because a file handle doesn't get cleaned up, then
> that's your fault, not the fault of the function which left a file
> handle to be closed by pool cleanup.
Does this mean you don't like what Brane did to the function with his patch?
There is / was a bug in the function itself: the function did not close a
file when trying to remove it. If this causes a handle leak on Windows that is
a problem which should be addressed. Branes patch does that.
Brane told me I was doing something dumb (removing before closing), although
I don't get why we had a leak since the APR docs say:
/**
* delete the specified file.
* @param path The full path to the file (using / on all systems)
* @param cont The pool to use.
* @remark If the file is open, it won't be removed until all instances are
closed.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*/
APR_DECLARE(apr_status_t) apr_file_remove(const char *path, apr_pool_t
*cont);
If there are better solutions, maybe we should postpone futher discussion
until after 1.0 if Branes patch works? The idea on which I have based the patch
I showed you in IRC yesterday is in my opinion a more elegant way of
addressing the problem, but I seem to have gotten on various nerves already and
discussion could be done later.
bye,
Erik.
PS: The patch can be retrieved at
http://encorps.dnsalias.com/svn-public/patches/svn_subst_copy_and_translate-cleanup.patch and probably needs cleanup
before it can be applied. It's the idea that counts.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 18 11:58:49 2003