apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmpil...@collab.net
Subject Re: [time to move on I guess] APR_TMP_DIRECTORY
Date Mon, 09 Dec 2002 16:26:02 GMT
Dirk-Willem van Gulik <dirkx@webweaving.org> writes:

> ...
> > its utilities, svnlook needs to create two temporary files to be used
> > by an external 'diff' process.  Given only handles, we have no paths
> But the svnlook lives longer than the diff process ? Or do you -also-
> postulate something like a 'crontab' which deletes cruft in case of
> accidents ?

In the case of accidents that cause svnlook itself to fail to cleanup
the tmpfiles (in both success and error cases), you can be sure that
some junk is left around.  Some externel mechanism must then clean
that stuff up.  What's a program to do?

> > to provide to that 'diff' process.  CVS gets around this by using an
> ....
> > Now, most of Subversion's operations require a working copy, so we
> > make our tempfiles in the .svn/tmp/ directory in those cases.  But we
> ...
> > across the network, with no working copy (and therefore no guaranteed
> > user-writable place to put tempfiles).
> Aye - well in that case I would personally would really want to have this
> done on application level and under operator control - as the associated
> environment (especially if you have thousands of accounts/connections to
> worry about) will often require extensive fitting to the maintenance
> model. It's a shame Unix, like windows, has no global registry :-)

Dirk, this is *ridiculous*.  I'm sorry, I really am trying to be
sensible here, but I get this feeling that you're trying to push some
sort of "programmer's best practices" policy agenda via crippling the
portability layer.  Sure, Subversion could implement the
get_temp_dir() function and use it.  But I guarantee that other
programs will have similar situations that require this functionality,
will expect it in the portability layer, will understand the security
consequences of taking this route, and will (now) be forced to
implement the same thing.

This *is* a portability question.  It *is* inside the domain of the
portability layer.  It *does* belong in APR.  And heck, you can
compose the 2-page "why you shouldn't use this" and stick in the
header file yourself if you'd like.

View raw message