apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: APR_TMP_DIRECTORY
Date Sun, 08 Dec 2002 15:04:45 GMT
Can I suggest that before we go headlong into letting the existing unix
api's decide on our new api we decide exactly what we want???? Jeez - though
the dog was supposed to wag the tail?

Implementation details are nice, but really until we know what we want to
implement they're a bit premature aren't they?

So, having spent 10 minutes reading email trying to catch up I'm still no
further forward apart from seeing a lot of totally irrelevant discussion of
Unix :( Anyone care to kick this back on topic so maybe some work can be
done or are we turning into Jakarta???

david

----- Original Message -----
From: "Wilfredo Sanchez" <wsanchez@apache.org>
To: "Apache Portable Runtime Developers" <dev@apr.apache.org>
Sent: Saturday, December 07, 2002 7:36 AM
Subject: Re: APR_TMP_DIRECTORY


> 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
>
>


Mime
View raw message