apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Date Thu, 05 Dec 2002 21:07:43 GMT

On Thu, 5 Dec 2002, William A. Rowe, Jr. wrote:

> At 01:05 PM 12/5/2002, Aaron Bannert wrote:
> >On Thursday, December 5, 2002, at 10:43  AM, William A. Rowe, Jr. wrote:
> >>As a developer/administrator/user, I *really* get ticked off by those
> >>developers who don't respect my system-wide %TEMP%/%TMP%
> >>assignments.  This isn't just a personal choice, since on locked down
> >>boxes or with apps installed on network filesystems, the cwd() is the
> >>very *worst* place to put tempfiles.
> >
> >This is precisely why the app needs to let the admin chose where to
> >put temp files.
> >
> >>That said, we also shouldn't force developers to give any thought to
> >>these things.  If the proposed solution walks down the chain until we
> >>find the most appropriate directory with create/write/rm access, then
> >>that code needs not be duplicated by every app.
> >>
> >>Yes, envvars are good (as long as they correspond to each platform's
> >>well-known envvar names.)  Let's not make apr counterintuitive for the
> >>real users/administrators.
> >
> >Personally, I really get ticked off when programs go off and do
> >weird things based on lame environment variables that I didn't
> >explicitly set. We want to simplify and unify the interface
> >to our programs, not cause unintended side-effects (or even
> >worse, open up conduits for other holes to exploit).
> >
> >I don't care if there's a default as long as it comes from the app.
> >If the app wants to default to %TEMP% or $TMP or whatever, that's
> >fine, let them shoot themselves in the foot, but don't hand them
> >the gun.
> Ok... here's how I see us finding common ground...
> Add an apr_filepath_temp_set() that allows the developer to override
> the temp path for an entire app; e.g. those apps which have a config
> directive SetTempPath /zzz can support their temp path config flag.
> Unless apr_filepath_temp_set() was invoked, all temp-dir related
> directives will use the "native" choice.

I'm sorry, but no.  If the application developer really doesn't want to
use the native method for choosing the temp directory, then they don't
have to.  David's suggestion provided three APIs for generating a
temporary file, one of them allows the user to provide a directory.  The
other two rely on the platform to provide the correct temporary directory.

Why in the world would we make it harder for apps to create temporary
files?  If httpd wants to create a directive for where to locate temporary
files, then the API that David proposed does that.  If the user doesn't
want to specify the directory, then the API that David proposed does that.

What exactly is the argument against using the proposed API?  That we
shouldn't use environment variables?  The environment variables are a
mechanism that some platforms use for locating the temp directory.  To
ignore them would be stupid and it would make it harder to APR app
developers to write their code.

Unless there is a much clearer explanation of why David's proposal
shouldn't be used, we should go ahead and implement it.


View raw message