apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: APR_TMP_DIRECTORY
Date Mon, 09 Dec 2002 15:26:53 GMT

> Great job at ducking the question.  It is really simple.  The application
> needs to create a temporary file.

I think we agree on this. APR already does this; libc has done this for a
long time.

Solet it do that; preferably using the file descriptor; tmpfile() name
which has a very clear contract:

->	Unique to you system wide.
->	Delete when last reference is closed.

and with well understood platform specific location semantics for the sys
admin. So that solves -the- problem I think APR should solve. And does so
very well.

> To do so, it would like to find a directory that houses temporary files

Why - if it already has a name or, preferably, a file descriptor ? Why
does it need to know the directory of the day ?

> so that if something happens, it can be deleted automatically with a
> cron job.

I am sure there are better mechanisms; such as close the FD and let the
file be gone. Before we know it we need to add temp file gargabge countrol
and an APR-deamon to do this crontabbing to make it complete. And add all
the semantics to make things unique.

> You are asking us to solve a problem but then saying that we can't solve
> it completely.

No - I maitain that APR should -NOT- solve the problem of abstracting
retrieval of the name of a tmp directory; 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.

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

So just solve the problem we can; and lets not solve the problem we should
not solve.

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.

Dw


Mime
View raw message