Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 7 Dec 2002 13:47:11 -0800
Mime-Version: 1.0 (Apple Message framework v548)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Re: APR_TMP_DIRECTORY
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez?= <wsanchez@wsanchez.net>
To: Apache Portable Runtime Developers <dev@apr.apache.org>
Content-Transfer-Encoding: 7bit
Message-Id: <71179CDA-0A2D-11D7-87F8-000393A5892E@wsanchez.net>

   (Had some trouble sending this mail.  Sorry if it goes out >1 time.) 
-wsv

On Wednesday, December 4, 2002, at 10:53  PM, David Reid wrote:

> Actually I think we should have 3 new functions...
>
> char *apr_temp_get_directory(apr_pool_t *)
> char *apr_temp_get_filename(char *dir, char *suffix, apr_pool_t *)
> char *apr_temp_get_unique(char *suffix, apr_pool_t *)
>
> This gives us the ability to let the users do what they like and 
> maximum
> flexability. apr_get_unique is mean to work along the lines of PHP's
> uniqid(), though do we also want to allow for extensions to be passed?
>
> david

For apr_temp_get_directory:

   I'm on the side that env vars appropriate to the platform should be 
honored.  But note that BSD Unix and I think POSIX do not dictate such 
a variable.  TMPDIR, if used, is used at the discretion of 
applications, not by the system per-se, though it's not uncommon for 
system applications to do so.  <paths.h> defines _PATH_TMP, which we 
should use.  Beware this includes the trailing slash, which I think is 
more of a bother than a help, but whatever.

   A note on /var/tmp:  On BSD systems, you have both /tmp and /var/tmp. 
  The difference is that /var/tmp tends to be longer-lived (files that 
haven't been accessed in n days get deleted by periodic tasks, n is 
sometimes larger for /var/tmp), and, unlike /tmp, is not wiped on 
reboot.  /var/tmp is generally used by system software, but also by 
editors for backup files (which you'd like to find even if your system 
crashed).  See hier(7).  Don't know about System V conventions for 
that.  Anyway, on BSD, I think we want /tmp, not /var/tmp for the 
default.

For apr_temp_get_filename:

   I suggest you look at the mktemp(3) API family on a BSD system for 
reference.  That API is pretty good.  There are some features there 
(one rather important one) missing in your API.

   mktemp take a template and returns a tmp file based on that template. 
  Basically, this lets you choose a prefix as well, which is useful for 
identifying the files.  (eg. /tmp/svn_turd.xxxx vs. 
/tmp/httpasswd_turd.xxxx) I think that's a good idea.

   Important one: Note that mktemp()  is similar yo your API in that it 
returns a string which is a path to a non-existing file in an existing 
directory.  The problem with that API is that there is a race 
condition; if the file is opened by another process between the time 
you get that string and when you attempt to create the file, you may 
loose.  mkstemp() differs in that it creates the file (mode 0600) and 
give you back a file descriptor.  I think we want that.

   I suggest we use something like this API:

char *apr_temp_get_filename(char *dir, char* prefix, char *suffix, 
apr_pool_t *)
apr_file_t apr_temp_file(char *dir, char* prefix, char *suffix, 
apr_pool_t *)

   There is also an mkdtemp() for creating a temporary directory (mode 
0700).  This is also handy.  So maybe we also want:

char* apr_temp_mkdir(char *dir, char* prefix, char *suffix, apr_pool_t 
*)

   And that we use mktemp() and friends (or tempfile() and friends or 
that crazy Windows API) before falling back to our own implementation.

For apr_temp_get_unique:

   Dunno what that is.  No comment.

	-wsv