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" <[EMAIL PROTECTED]> 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 > >
