apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Date Mon, 09 Dec 2002 17:46:14 GMT
At 09:26 AM 12/9/2002, Dirk-Willem van Gulik wrote:

>No - I maitain that APR should -NOT- solve the problem of abstracting
>retrieval of the name of a tmp directory

What you are maintaining is that APR should not handle the platform
ambiguities of where TMP files should be stored on a given platform.
APR is only about platform neutrality.  Your arguement makes no sense.

The idea of a temp directory is a quite portable construct.  Where any 
given platform stores such temp files (or how to resolve where they are
stored) is not a portable construct.


> but restict itself of providing a, preferably, FD to a temp file (or many 
>tmp files) with very clear semantics and a clear live time contract.

Which addresses the pure temp file.  It doesn't address tmp directories
(e.g. I want to unpack an archive, where shall I put it?) and it doesn't
address persistent tmp files (I don't care if it survives, but when it does
survive one invocation to another of my app, it sure would speed things
up if I can retrieve some cached data.  And if I can't, no loss (but speed.)

>And leave the problem of a temp dir with semantics specific to the
>application to that application.

Which leaves every app solving a portability problem.  That's where 
you've lost me (and perhaps Ryan and others as well.)

>The reason I am very fierce about this is that time and time again I run
>into applications which when moved to either a secure Solaris installation
>or when deployed with complex NetApp or boot-from-diskless/read-only
>system disk have started to fail or cause mysterious crashes. As some app
>somewhere deceided to clash with the temp dir of another; or in order to
>get one to work I had to resort to /tmp (in swap space on Solaris) but
>then had to bend over backwards to make sure that another app used some
>/nfs/tmp as that one required preserve across boot semantics for its
>'temp' file storage. All that was app driven; so I feel strongly that it
>thus should be app controlled.

If they respected your TMPDIR setting?  What then, wouldn't that app
have behaved quite nicely?

I believe we are all saying that a hardcoded setting is the absolute
worst choice.  Look for a better choice (a user-config option is best,
then an envvar specific to the platform, and at worst case a known


View raw message