cmpilato@collab.net writes:
> This is your reminder notice (sent also to the world for
> recording and accountability purposes) to examine the necessity of the
> svn_io_check_path() call in libsvn_client/commit.c:remove_tmpfiles().
Thanks. Folks: Mike looked at this code in remove_tmpfiles():
/* Clean up any tempfiles. */
for (hi = apr_hash_first (pool, tempfiles); hi; hi = apr_hash_next (hi))
{
const void *key;
void *val;
svn_node_kind_t kind;
svn_pool_clear (subpool);
apr_hash_this (hi, &key, NULL, &val);
SVN_ERR (svn_io_check_path ((const char *)key, &kind, subpool));
if (kind == svn_node_file)
SVN_ERR (svn_io_remove_file ((const char *)key, subpool));
}
and asked "Why are we calling svn_io_check_path()?" Our conclusion
was that there might be circumstances where the tmpfile has already
been removed -- in which case, the code would be a little more
self-explanatory if the condition read
if (kind != svn_node_none)
SVN_ERR (svn_io_remove_file ((const char *)key, subpool));
As a bonus, that would also conveniently error if non-file objects
were somehow found where files were expected. Question is: in these
modern times, are there ever circumstances when a tmpfile is already
gone from disk by the time we reach this code? If there aren't, then
both the call and the associated condition can go away entirely.
I'm going to comment out the svn_io_check_path() and make the removal
unconditional, then run the test suite. But that won't necessarily
provide a 100% reliable answer, so I also wanted to ask here, in case
anyone remembers anything about the logic of this code...
Let me know,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 9 20:19:20 2003